Менеджеры ИТ-инфраструктуры все яснее осознают важность защиты данных и приложений от постоянно растущих угроз. Программы-вымогатели (ransomware), в частности, становятся всё более разрушительными, требуя надёжных и инновационных решений.

На VMware Explore 2024 в Лас-Вегасе Broadcom представила значительные улучшения VMware Live Recovery, комплексного решения, разработанного для защиты среды VMware Cloud Foundation как от атак вымогателей, так и от традиционных катастроф.

• Быстрота и уверенность в условиях кризиса - VMware Live Recovery предлагает и то, и другое. Когда случаются атаки вымогателей или катастрофы, скорость и уверенность являются решающими факторами для успешного восстановления.
• Унифицированный подход к киберустойчивости - VMware Live Recovery отвечает потребностям в восстановлении как после атак вымогателей, так и при катастрофах. Используя комбинацию механизмов безопасного восстановления, защиты east-west и укрепленной (hardened) инфраструктуры, VMware гарантирует, что критически важные рабочие нагрузки защищены в вашей среде VMware vSphere.
• Ускоренное восстановление и упрощённое использование - VMware Live Recovery предоставляет мощную киберустойчивость и устойчивость данных для VMware Cloud Foundation. Это решение обеспечивает восстановление после атак вымогателей и катастроф в унифицированной системе управления, с ускоренным процессом восстановления и упрощенным потреблением, с гибким лицензированием для различных сценариев и облаков.
• Защита вашей виртуальной среды VMware - с помощью VMware Live Recovery вы можете защищать свою среду VMware на различных платформах: в вашем локальном датацентре, в VMware Cloud на AWS или другом облачном провайдере. Это гарантирует защиту от широкого спектра угроз, включая ransomware, аппаратные сбои и природные катастрофы.

Какие новые возможности были представлены на VMware Explore 2024:

1. Локальное восстановление vSAN
2. Удалённая репликация снимков vSAN
3. Изолированная среда восстановления в собственном датацентре (On-Premises Isolated Recovery Environment, IRE)

Локальное восстановление vSAN

Теперь вы можете применять ускоренное до 16 раз обратное восстановление (failback) из VMware Cloud на AWS, используя локальные снимки VMware как основу для процесса восстановления, восстанавливая только проверенные изменения. Это приводит к 75%-му сокращению времени простоя, минимизируя сбои в работе.

Удалённая репликация снапшотов vSAN

Теперь расширены возможности локальных снимков vSAN для создания удалённых снимков, что позволят сохранять более глубокую историю неизменяемых снимков (до 200) с помощью унифицированного виртуального модуля (Virtual Appliance) для управления. Эта новая функция обеспечивает репликацию vSAN-to-vSAN и позволяет достичь следующих результатов:

• Повышенная устойчивость данных: до 200 точек восстановления на ВМ.
• Снижение простоев, благодаря опыту VMware в оркестрации восстановления.
• Упрощённое управление: единый модуль упрощает процесс.
• Повышенная масштабируемость и эффективность: использование кластеров хранения vSAN улучшает производительность.

Преимущества локальной изолированной среды восстановления (IRE)

Теперь у вас есть гибкость и возможность выбора изоляции VCF (VMware Cloud Foundation) как на локальной инфраструктуре, так и в облаке, что обеспечивает суверенитет данных и соответствие нормативным требованиям. Новая локальная изолированная среда восстановления предоставляет возможности кибервосстановления там, где вам удобно — в изолированной среде восстановления, размещенной в VMware Cloud на AWS, или для клиентов, желающих хранить данные локально, на собственной площадке.

Особенности:

• Гибкость и выбор: выбирайте изолированные "чистые комнаты" VCF локально или в облаке.
• Суверенитет данных: сохраняйте контроль над своими данными и обеспечивайте соответствие требованиям конфиденциальности и местонахождения данных.
• Интеграция полного стека: раскройте потенциал интегрированной киберустойчивости VCF для защиты рабочих нагрузок в любом месте.

Более подробно о новых возможностях VMware Live Recovery вы можете узнать из записанных сессий на VMware Explore.

В этом году на VMware Explore 2024 в Лас-Вегасе компания VMware представила новую версию платформы Tanzu Platform 10. Этот новый релиз предназначен для современных предприятий и направлен на трансформацию управления, обеспечения безопасности и оптимизации приложений с улучшенной гибкостью и возможностями мониторинга. Tanzu Platform 10 позволяет выбирать между Cloud Foundry и Kubernetes в качестве среды выполнения, будь то в публичных или частных облаках. Такая гибкость обеспечивает возможность адаптации Tanzu Platform под конкретные нужды вашего бизнеса. Если вы используете Cloud Foundry, теперь вы можете также подключиться и к экосистеме Kubernetes и воспользоваться надежной интеграцией данных, продолжая использовать уникальные функции Cloud Foundry. Вы также получите более глубокую видимость своих систем благодаря улучшенному пользовательскому интерфейсу и усовершенствованиям в области безопасности, циклов развертывания и создания приложений с поддержкой GenAI.

GenAI для Tanzu Platform теперь в публичной бета-версии

Проект, начавшийся на хакатоне на прошлом VMware Explore, вырос в публичную бета-версию GenAI для Tanzu Platform, запущенную в июне. В VMware рады представить еще больше функций и обновлений в последней публичной бета-версии, включая дополнительные возможности для разработчиков, чтобы быстрее и эффективнее создавать приложения в Tanzu Platform для Cloud Foundry.

На волне успеха GenAI в Tanzu Platform компания VMware объявляет о новых возможностях, которые помогут текущим и будущим клиентам Tanzu Platform создавать корпоративные приложения с поддержкой GenAI. VMware Tanzu AI Solutions — это революционный набор возможностей, доступных в Tanzu Platform, который поддерживает организации в ускорении и масштабировании безопасной поставки интеллектуальных приложений.

Последние функции, доступные в публичной бета-версии, включают:

• Поддержку VMware vSphere, Google Cloud Platform, AWS и Azure
• Безопасный и приватный доступ к совместимому с OpenAI API через Tanzu AI Server
• Брокер для моделей, работающих на VMware Private AI Foundation и моделях сторонних поставщиков
• Развертывание частных больших языковых моделей (LLM) через BOSH в вашей инфраструктуре Tanzu Platform для Cloud Foundry
• Поддержка открытых моделей через vLLM и Ollama, а также поддержка доступа к приватным или ограниченным репозиториям Hugging Face
• Поддержка Nvidia GPU (vGPU и режим pass-through) и Intel Xeon CPU (производительность может варьироваться в зависимости от модели и поколения процессора)

Мультиинфраструктурная видимость теперь доступна в Tanzu Platform для Cloud Foundry

Tanzu Platform 10 предоставляет сквозной мониторинг, позволяя командам платформ отслеживать весь жизненный цикл приложений. От начальных коммитов кода до развертывания в продакшн, вы получите полное представление о производительности, ошибках и использовании ресурсов.

В последнем релизе Tanzu Platform 10 теперь поддерживаются мультиинфраструктурные представления и улучшенная видимость Tanzu Platform для Cloud Foundry, что позволяет инженерам платформ видеть все свои системы и компоненты в одном месте. Это упрощает устранение проблем со "здоровьем приложений" во всех развертываниях Cloud Foundry, включая дополнительные возможности для встраивания проверок здоровья в Tanzu Platform.

Интерфейс Tanzu Platform hub, который объединяет инфраструктуры в едином представлении:

Функции, которые будут доступны в Tanzu Platform for Cloud Foundry 10, включают:

• Просмотр всех платформ (Multi-foundation view): Tanzu Platform предоставляет возможность видеть все ваши платформы в одном консолидированном представлении. Это объединение упрощает управление приложениями на различных платформах, предлагая более четкую картину всей вашей экосистемы.
• Снижение затрат (Cost Savings): Используя интегрированное представление центра Tanzu Platform, команды платформ могут сэкономить деньги за счет сокращения потребности в сторонних продуктах. Эта интеграция не только снижает затраты, но и упрощает операции, повышая эффективность и контроль вашего бизнеса.
• Метрики в одном представлении (At-a-glance metrics): Интуитивно понятная панель управления Tanzu Platform предлагает простые метрики для всех платформ. Эта функция позволяет быстро оценить состояние всей вашей среды Cloud Foundry, включая количество приложений и сервисов, работающих на каждой платформе. Этот всеобъемлющий обзор обеспечивает своевременное выявление и устранение проблем.

Посмотрите демонстрацию работы Tanzu Platform в действии в этом эпизоде подкаста Cloud Foundry Weekly.

Прозрачность безопасности

В сегодняшней среде ограничение угроз безопасности имеет первостепенное значение. Tanzu Platform 10 делает акцент на прозрачной модели безопасности, позволяя командам четко видеть и понимать действующие меры безопасности. Это облегчает обнаружение уязвимостей и соблюдение требований, при этом сохраняется целостность ваших приложений.

Теперь в Tanzu Platform 10 клиенты могут анализировать список компонентов программного обеспечения (SBOM) своих приложений, чтобы выявлять устаревшие библиотеки и быстро предоставлять разработчикам информацию о том, какие действия необходимо предпринять для обновления кода приложения. Это также позволяет инженерам платформ поддерживать актуальность библиотек и обеспечивать непрерывные обновления платформы для снижения рисков безопасности.

Быстрее циклы развертывания с улучшенными возможностями для разработчиков

В основе работы VMware с сообществом лежит поддержка разработчиков. Tanzu Platform 10 представляет улучшенные возможности для разработчиков, предлагая надежные инструменты и интеграции, которые упрощают процесс разработки.

В Tanzu Platform 10 канареечные и прокатные развертывания помогут клиентам улучшить опыт развертывания, повысить продуктивность и ускорить циклы развертывания. Канареечные развертывания позволяют тестировать новую сборку на небольшом объеме пользователей, сохраняя старую сборку для большей части трафика.

Клиенты также могут оценить улучшения в автоматическом масштабировании приложений благодаря переработанной архитектуре CF CLI. Автоматическое масштабирование приложений можно применять к еще большему количеству приложений для увеличения времени запуска и улучшения общей устойчивости приложений.

Непрерывные обновления, сертификации и улучшения платформы

Клиенты могут ожидать более плавных обновлений, более легкого отслеживания процесса ротации сертификатов и многочисленных улучшений платформы, разработанных для повышения удобства использования и производительности. Эти улучшения позволяют вашей платформе оставаться на переднем крае инноваций и быть готовой к удовлетворению меняющихся требований бизнеса.

Также дополнительные сведения о VMware Tanzu Platform 10 вы можете узнать тут и тут.

В VMware на протяжении многих лет прислушивались к клиентам и понимают, насколько важно для них иметь стабильную и безопасную инфраструктуру. Несмотря на то что все больше компаний переходят на последние версии VMware Cloud Foundation (VCF) 5.x, некоторые из них находятся в процессе планирования своих обновлений с VCF 4.x.

Чтобы облегчить этот переход и предоставить больше гибкости, недавно было объявлено о продлении периода общей поддержки VMware vSphere 7.x.

Изначально vSphere 7.x должна была достичь окончания общей поддержки 2 апреля 2025 года. С этим объявлением общий период поддержки был продлен до 2 октября 2025 года.

Продление этой поддержки будет осуществляться с учетом следующих условий:

• В течение периода продленной общей поддержки Broadcom будет стремиться решать любые критические уязвимости в исходном коде, которые могут быть обнаружены. Однако возможность обновления компонентов с открытым исходным кодом, включая обновление до более новой версии пакета, зависит от различных факторов, включая, но не ограничиваясь доступностью патча в upstream и поддержкой версии пакета его разработчиками.
• Broadcom не гарантирует, что будут выпущены обновления для всех выявленных уязвимостей в исходном коде. Broadcom оставляет за собой право не включать исправления ошибок, уязвимостей безопасности или любое другое обслуживание компонентов с открытым исходным кодом, даже если они доступны в upstream.
• Последняя поддерживаемая версия Kubernetes на VCF 4.x (vCenter 7.x) будет минорной версией 1.28. Клиентам, использующим панель управления vSphere IaaS, следует планировать переход на vCenter 8.x до окончания общей поддержки Kubernetes v1.28 28 мая 2025 года. Начиная с vCenter 8.0 Update 3, служба TKG может быть обновлена независимо для поддержки новых версий Kubernetes.
• В vSphere 7.x включен встроенный реестр Harbor, который можно активировать на Supervisor кластере для хранения и обмена образами контейнеров. Поддержка этого встроенного реестра Harbor на vSphere 7.x не будет продлена в период продленной общей поддержки. Клиенты, использующие встроенный реестр Harbor, могут выбрать один из следующих вариантов:
  • Рассмотреть возможность миграции на внешний частный реестр контейнеров на продленный период.
  • Обновиться до последней версии vSphere 8.x и перейти на использование службы Harbor Supervisor.

С ростом числа сценариев использования генеративного AI, а также с существующими рабочими нагрузками AI и машинного обучения, все хотят получить больше мощностей GPU и стремятся максимально эффективно использовать те, которые у них уже есть. В настоящее время метрики использования GPU доступны только на уровне хоста в vSphere, а с помощью модуля vSphere GPU Monitoring вы теперь можете видеть их на уровне кластера. Эта информация имеет большое значение для таких задач, как планирование ёмкости, что оказывает значительное стратегическое влияние на организации, стремящиеся увеличить использование AI.

vSphere GPU Monitoring Fling предоставляет метрики GPU на уровне кластера в VMware vSphere, что позволяет максимально эффективно использовать дорогостоящее оборудование. Он совместим с vSphere версий 7 и 8. Также функционал утилиты также доступен в виде основного патча vCenter 8.0 Update 2 для тех, кто использует более новые версии платформы (то есть, Fling не требуется!). Скачайте плагин здесь и поделитесь своим мнением в разделе Threads на портале community.broadcom.com или по электронной почте vspheregpu.monitoring@broadcom.com.

Пользователям нужно провести установку плагина для объекта Datacenter, после чего они смогут видеть сводные метрики своих GPU для кластеров в этом датацентре. В представлении датацентра пользователь может нажать на «View Details», чтобы увидеть более подробную информацию о распределении и потреблении GPU, а также о типе совместного использования GPU.

Наконец, температура также является важной метрикой для отслеживания, так как долговечность и производительность GPU значительно снижаются, если они слишком долго работают при высокой температуре. Этот Fling также включает и мониторинг температуры:

В VMware Cloud Foundation (VCF) версии 5.2 появилась новая консоль, которая добавляет диагностические возможности в Operations VMware Cloud Foundation (VMware Aria Operations). VMware Cloud Foundation Operations включен в VCF и VMware vSphere Foundation.

Новые функции включают "Общие выводы" и "Рекомендации по безопасности". Кроме того, такие разделы, как "Серверы vCenter", "Хосты ESXi", "Развертывание рабочих нагрузок" и "Кластеры vSAN", которые ранее были доступны в VMware Cloud Foundation Operations, теперь включены для улучшенной видимости. Также улучшена интеграция с VMware Aria Operations for Logs, что предоставляет больше информации о миграциях vMotion и снапшотах. Чтобы включить эту функцию, необходимо подключить Operations к Operations for Logs и хотя бы одному vCenter. При добавлении дополнительных компонентов VMware vSphere Foundation и VCF станут доступны дополнительные наборы данных. Давайте рассмотрим каждый раздел более подробно.

Общие выводы

В новой версии VMware Cloud Foundation Operations объединены диагностические возможности (из Skyline Health Diagnostics, Skyline Advisor и VMware Aria Operations for Logs) в единый интерфейс, представленный в новой консоли. С помощью Skyline можно применять рекомендации по безопасности и эксплуатации на основе версий. Теперь VMware Cloud Foundation Operations и VMware Aria Operations for Logs привязаны к одним и тем же конечным эндпоинтам, что способствует появлению новых диагностических выводов в консоли, уменьшая необходимость в развертывании дополнительного программного обеспечения (сокращает необходимость в Skyline Advisor Collector и виртуальной машине Skyline Health Diagnostics). Эта бесшовная интеграция уменьшает дублирование усилий, о которых упоминалось ранее, и упрощает развертывание и управление средой. В результате получается системный подход к представлению диагностических выводов клиентам.

Вот некоторые распространенные задачи:

• Просмотр всех файндингов
• Определение общего количества ресурсов
• Категоризация выводов по критичности (критические, срочные и предупреждения)
• Классификация по типу:
  • Рекомендации по безопасности
  • Доступность
  • Проверки перед обновлением
  • Диагностика эксплуатации
  • Производительность
• Уточнение их представления с помощью фильтров на основе:
  • Инвентарь VCF
  • Компоненты VCF
  • Тип файндинга
  • Серьезность
  • Возможности:
    • vMotions
    • Снапшоты
    • Развертывание рабочих нагрузок
    • Домены рабочих нагрузок
      • DRS
      • HA

Для доступа к диагностической консоли выберите "Diagnostics" в левой панели навигации. На странице Home -> Overview найдите ссылки на "Appliances Health & Management".

Рисунок 1. Дэшборд главной страницы.

Рисунок 2. Дэшборд диагностики из меню слева.

В основном дэшборде «Overall Findings» вы можете быстро просмотреть все файндинги. Вы можете уточнить их количество, выбрав компоненты в левой панели. Кроме того, вы можете искать конкретные файндинги или использовать подстановочные знаки в строке поиска, расположенной выше списка файндингов.

Рисунок 3. Опции фильтрации и поиска на панели «Diagnostic Findings».

Вы можете углубиться в просмотр конкретных деталей, выбрав отдельный файндинг, например, Last Observed, Affected Objects и Recommendations.

Рисунок 4. Просмотр Last Objerved и Affected Objects.

На вкладке «Affected Objects» вы можете найти имя объекта, время его первого наблюдения (Occurrence Time) и время последней проверки (Check Time). Окружение будет сканироваться каждые четыре часа, и детали на этой вкладке будут обновляться соответственно. Не забудьте учитывать следующую информацию:

Рисунок 5. Просмотр деталей «Affected Objects».

В разделе «Recommendations» вы можете найти версию продукта, в которой проблема была решена, а также статью базы знаний (KB), в которой представлены детали о проблеме, исправлении и воркэраунде.

Рисунок 6. Просмотр рекомендаций по исправленным версиям и статьям базы знаний (KB).

Вот некоторые распространенные сценарии использования:

• Просмотр VMSA и CVE для определения возможных проблем и обновлений для определенного набора серверов.
• Помощь в планировании обновлений vCenter и ESXi для решения нескольких файндингов одновременно.
• Разделение списка файндингов по регионам, чтобы распределить работу среди сотрудников, работающих в разных регионах.

Управление сертификатами

Все сертификаты в среде будут отображены здесь. Эти сертификаты существуют во всех приложениях VMware для обеспечения идентификации приложений (с целью уменьшения риска атак типа «man in the middle»). Поскольку каждое приложение может иметь до трех сертификатов, управление сертификатами занимает много времени и является сложным процессом. С учетом даты истечения срока действия и внешнего центра сертификации, управление графиком обновления и импорта сертификатов может вызывать проблемы.

Когда вы настраиваете консоль диагностики, то заполняется и панель управления сертификатами. Вы можете легко увидеть все сертификаты для конкретного сервера, включая информацию о том, являются ли они самоподписанными или сертификатами CA, а также активны ли они. Для активных сертификатов пользователи могут увидеть оставшееся время до истечения срока действия, что помогает начать процесс обновления сертификатов до их истечения, чтобы предотвратить возможные перебои в работе.

Рисунок 7. Обзор дэшборда управления сертификатами.

Вот некоторые распространенные сценарии использования:

• Проверка наличия «неактивных» сертификатов и их немедленное исправление.
• Просмотр даты истечения срока действия и немедленное исправление самоподписанных сертификатов.
• Превентивное предотвращение истечения срока действия сертификатов.

vCenter

В дэшборде диагностики vCenter вы можете легко просмотреть все vCenter, подключенные к VCF Operations. Здесь объединяются все данные из vCenter, а также данные из VCF Operations. Вы можете быстро проверить операционный статус каждого vCenter. Если какой-либо vCenter не работает, вы можете определить количество затронутых хостов ESXi и виртуальных машин. Кроме того, вы можете увидеть все службы, запущенные на конкретном vCenter. В течение нескольких секунд можно определить, какие службы не работают, устранить проблемы и вернуть их в рабочее состояние. Этот процесс занял бы 30 минут или больше, если бы использовались традиционные методы, такие как проверка vCenter через консоль сервера и файлы журналов. При необходимости можно выбрать отдельные vCenter для более детального исследования.

Рисунок 8. Дэшборд vCenter.

Вот некоторые распространенные сценарии использования:

• Проверка доступности любого vCenter и определение затронутых серверов и виртуальных машин.
• Просмотр служб на каждом vCenter, чтобы убедиться, что все они работают нормально.

Хосты ESXi

Дэшборд ESXi предоставляет важную диагностическую информацию о хостах ESXi. Во-первых, вы можете проверить наличие «неотвечающих ESXi» серверов, так как это вопросы высокого приоритета. Далее, вы можете проверить, находятся ли какие-либо ESXi серверы в режиме обслуживания и определить, должны ли они оставаться в этом режиме или выйти из него. Также важно обратить внимание на серверы ESXi, которые были «отключены» или «не отвечают» в течение длительного времени. При выборе каждого ESXi сервера вы можете получить доступ к настройкам «родительского кластера», что может предоставить ценные сведения о возможных проблемах. В течение нескольких секунд можно выявить проблемы и инициировать необходимые действия по их устранению.

Рисунок 9. Дэшборд ESXi.

Вот некоторые распространенные сценарии использования:

• Выявление всех «не отвечающих» серверов ESXi и их восстановление до нормального состояния.
• Проверка ESXi режиме обслуживания для уверенности в том, что они действительно должны там находиться. Вывод из режима обслуживания как можно скорее для оптимального использования ресурсов.
• Определение «Родительского кластера» конкретного ESXi и проверка правильности всех настроек.

Развертывание рабочих нагрузок

На панели управления развертыванием рабочих нагрузок вы можете просмотреть общие задачи по управлению нагрузкой, такие как «Создать новую виртуальную машину», «Развернуть OVF» и «Клонировать виртуальную машину». Вы можете быстро выявить любые сбои. При просмотре деталей пользователи могут увидеть информацию, такую как «Время запроса», «Имя виртуальной машины», «Инициатор», «vCenter» и «Кластер». С этой информацией вы можете исследовать окружение на наличие потенциальных проблем, выполнить необходимые исправления и уведомить инициаторов о необходимости повторного выполнения их задач.

Рисунок 10. Дэшборд развертывания рабочих нагрузок.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных с развертыванием рабочих нагрузок.
• Проверка любых сбоев для выявления основной причины проблемы.
• Просмотр «инициаторов», чтобы убедиться, что все пользователи правильно назначены.

Миграции vMotion

Технология vMotion существует уже достаточно давно. Вы можете наблюдать за активностью vMotion в списке «recent tasks» в консоли vCenter. Однако ранее не было возможности видеть все события vMotion из одного представления. Теперь у вас есть такая возможность. Вы можете выбрать каждый vCenter, чтобы просмотреть все случаи vMotion, определяя как сбои, так и успешные события. В случае сбоя вы можете просмотреть такие детали, как имя виртуальной машины, источник, назначение и время, что поможет выявить и устранить проблему, предотвращая аналогичные сбои в будущем. Для тех, кто использует HCX (который использует vMotion), также фиксируются все активности HCX vMotion.

Рисунок 11. Дэшборд vMotion.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных с vMotion.
• Просмотр всех локаций, а также каждого vCenter на основе прошлых проблем.
• Проверка исходного и целевого хостов для выявления проблем.

Снапшоты

В диагностической консоли вы можете просмотреть все снапшоты в окружении. Вы сможете определить наиболее проблемные виртуальные машины с проблемами снапшотов, особенно те, которые требуют консолидации. Еще один важный аспект — оценка общего количества снимков для семи наиболее важных виртуальных машин. У вас есть возможность фильтровать успешные и неудачные снимки. Для каждой проблемы, связанной со снимками, вы можете просмотреть такие детали, как виртуальные машины, vCenter, хранилище данных и временная метка. Это должно предоставить достаточно информации, чтобы определить, является ли проблема специфичной для конкретной виртуальной машины или это системная проблема, связанная с vCenter, ESXi или хранилищем данных.

Рисунок 12. Дэшборд снапшотов.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных со снапшотами.
• Просмотр любых сбоев.
• Сопоставление любого сбоя с проблемой ESXi, графиком резервного копирования или другими сбоями (сеть, хранилище и т.д.).

Кластеры vSAN

Раздел «vSAN Health» в диагностической консоли предоставляет обзор состояния инфраструктуры vSAN. Вы можете быстро отфильтровать количество предупреждений «Красного», «Оранжевого» и «Желтого» уровня. При выборе каждого кластера появятся детали о свойствах выбранного кластера, которые помогут убедиться, что все необходимые настройки корректны. Ниже вы можете просмотреть детали каждого предупреждения, что поможет правильно расставить приоритеты и устранить проблемы для обеспечения наилучшей производительности и стабильности кластера vSAN.

Рисунок 13. Панель управления здоровьем vSAN.

Вот некоторые распространенные сценарии использования:

• Просмотр всех предупреждений «Красного», «Оранжевого» и «Желтого» уровня.
• Проверка всех свойств выбранного кластера на правильность настроек.
• Прохождение по всем выводам по отдельности для планирования обновления с целью решения проблем.

После изучения всех функций в диагностической консоли (файндинги, сертификаты, vCenter, ESXi, развертывание рабочих нагрузок, vMotion, снапшоты и кластеры vSAN) вы можете оценить значимость новых дэшбордов. Некоторые из них представляют собой недавно добавленные функции из других продуктов, а другие — это детали существующих панелей, объединенные в этой консоли. Цель заключается в предоставлении ценных сведений с минимальными усилиями по развертыванию и настройке. Это позволит использовать существующие экземпляры Aria Operations и Operations for Logs, что в конечном итоге сэкономит время клиентов на решение проблем и сократит время простоя и обслуживания.

В рамках функционала Configuration Profiles платформы VMware vSphere вы можете создать пользовательское определение аларма, который будет срабатывать, когда один или несколько хостов в кластере не соответствуют заданной конфигурации. Определение аларма можно создать на уровне vCenter или кластера (а также на уровнях папок и объекта datacenter). Для упрощения можно создать одно определение аларма на уровне vCenter, чтобы одно и то же определение применялось ко всем кластерам...

На прошлой неделе мы писали о новых возможностях следующих продуктов:

• VMware NSX 4.2
• Aria Operations 8.18
• Aria Suite Lifecycle 8.18
• Aria Operations for Networks 6.3

Все они стали доступны одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware HCX 4.10, предназначенное для миграции с различных онпремизных инфраструктур (как на платформе vSphere, так и Hyper-V или KVM) в облако на базе VMware Cloud и между облаками.

VMware HCX 4.10.0 является минорным релизом, который предоставляет новые функции, улучшения совместимости и удобства использования, а также обновления безопасности и исправления. Важные изменения касаются лицензионного фреймворка, улучшения управления трафиком, миграции, интерконнекта и поддержки различных систем.

Давайте посмотрим на новые возможности VMware HCX 4.10:

Важная информация

В версии HCX 4.9.0 VMware ввела единый лицензионный фреймворк для активации продуктов VMware Cloud Foundation и VMware vSphere Foundation. При обновлении до HCX 4.10 с версии ниже HCX 4.9.0, ознакомьтесь с изменениями в лицензировании и активации, описанными в заметках к релизу HCX 4.9.0. Всем существующим клиентам HCX, не использующим hyperscaler-облака, рекомендуется обновиться как можно скорее для обеспечения наивысшего уровня поддержки и портируемости продуктов VMware.

Улучшения управления трафиком

• Настраиваемое шифрование транспорта для миграции и трафика расширения сети: по умолчанию трафик миграции и расширения сети HCX зашифрован. В этой версии введена опция Service Mesh для активации или деактивации шифрования для каждого из этих сервисов. Отключение шифрования доступно для безопасных сетей Uplink.
• Generic Receive Offload (GRO): для входящего трафика расширения сети можно настроить GRO в настройках Traffic Engineering для Service Mesh, что улучшает производительность приложений.

Улучшения миграции

• Параметризация сайтов с не-vSphere для OS Assisted Migration (OSAM): теперь можно связывать сайты не на базе vSphere с HCX Connector или HCX Cloud Manager для миграции рабочих нагрузок с помощью OSAM, упрощая процесс миграции.
• HCX Assisted vMotion: новый тип миграции, работающий в сочетании с native cross-vCenter vMotion для оркестрации миграций между хостами VMware ESXi.
• Поддержка новых гостевых ОС для OSAM: Поддерживаются дополнительные операционные системы, такие как RHEL 8.9 и выше, Ubuntu 20.04 и 22.04, а также Rocky Linux 8.4 и выше.
• Массовая миграция (per-VM EVC): включает опцию деактивации Enhanced vMotion Compatibility для отдельных виртуальных машин.
• Миграция тегов vCenter: введена репликация тегов vCenter с исходного сайта на целевой сайт для более удобной настройки.

Улучшения интерконнекта

• HCX Intrasite Control Network: Новый тип сети для связи между HCX Interconnect и WAN Optimization, что разгружает задачи от сети Management Network.
• Конфигурация Compute Profile: HCX проверяет, что все профили сети охватывают все кластеры, чтобы предотвратить ошибки развертывания.

Улучшения расширения сети

• Разрешение пересекающихся подсетей: появилась опция разрешения пересекающихся подсетей для Network Extension, что полезно в случаях, когда сети имеют разные vLAN.

Улучшения совместимости

• VMware Cloud Foundation 5.2: HCX 4.10 совместим с VMware Cloud Foundation 5.2, улучшая масштабируемость и отказоустойчивость.
• VMware vSphere/vSAN 8.0 Update 3: поддержка миграций для виртуальных машин, использующих HW версию 21.
• VMware NSX 4.2: поддержка всех сетевых и миграционных функций в средах vSphere с NSX 4.2.
• VMware vSAN Max: возможность использования хранилищ vSAN Max в качестве целевых для мигрируемых рабочих нагрузок.

Улучшения пользовательского интерфейса

• Интерфейс Site Pairs: Теперь связанные сайты отображаются как отдельные карточки.

• Интерфейс Interconnect: локальные менеджеры Interconnect теперь показывают настройки Network Profile, Compute Profile и Service Mesh в одном месте.

• Конфигурация Service Mesh: включает отдельные мастера для создания Service Mesh для сайтов на основе vSphere и не-vSphere.

Эти улучшения делают VMware HCX 4.10.0 более мощным инструментом для миграции и управления сетями, обеспечивая повышение производительности, безопасности и удобства использования.

Подробнее обо всем этом вы можете почитать в Release Notes.

На днях мы писали о новых возможностях продуктов VMware NSX 4.2 и Aria Operations 8.18, которые стали доступны одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware Aria Operations for Logs 8.18, предназначенное для администраторов, сотрудников технической поддержки и системных инженеров, которые ищут причины проблем различного характера в облачной инфраструктуре на базе VMware Cloud и решают их на базе аналитики лог-файлов.

Давайте посмотрим на новые возможности VMware Aria Operations for Logs 8.18:

Поддержка единого входа (SSO) для VMware vSphere Foundation

В новой версии VMware Aria Operations for Logs 8.18 введена поддержка единого входа (SSO) с использованием VMware vCenter в качестве провайдера SSO. Теперь поддерживается импорт пользователей и групп из SSO провайдера, что упрощает управление доступом.

Улучшения пользовательского опыта

Страницы конфигурации интеграции VMware vSphere и VMware Aria Operations стали более интуитивными и удобными. Это обеспечивает более плавный и упрощенный процесс настройки.

Поддержка JSON для потребления логов

Теперь VMware Aria Operations for Logs поддерживает потребление логов в формате JSON, помимо формата Syslog, и потребление с помощью агента VMware Aria Operations for Logs. Это расширяет возможности работы с логами и улучшает совместимость с различными системами.

Поддержка VMware Aria Operations Cloud Proxy

В данной версии улучшена поддержка VMware Aria Operations Cloud Proxy для потребления и агрегации логов с последующей отправкой в VMware Aria Operations for Logs. Это обеспечивает более эффективное управление логами из облачных сред.

Документация API в формате Swagger

Теперь VMware Aria Operations for Logs поддерживает документацию API в формате Swagger. Это упрощает работу разработчиков и интеграцию с другими системами, предоставляя подробную информацию о доступных API.

Исправления безопасности

В этой версии устранено множество уязвимостей. Подробную информацию о безопасности и влиянии этих уязвимостей на продукты VMware можно найти в базе знаний KB 369221. Эти исправления повышают общую безопасность системы и защищенность данных.

Улучшения производительности

Производительность запросов, содержащих фильтры с полями, извлеченными с помощью регулярных выражений, была оптимизирована. Это улучшает скорость и эффективность работы с логами, особенно при сложных запросах.

Новые пакеты контента

В портале VMware Marketplace теперь доступны пакеты контента для следующих продуктов VMware:

• VMware HCX
• VMware vSphere с Tanzu

Эти пакеты контента позволяют расширить функциональность VMware Aria Operations for Logs и обеспечивают дополнительные возможности для мониторинга и управления логами.

Данные нововведения делают VMware Aria Operations for Logs 8.18 мощным инструментом для управления и анализа логов, улучшая производительность, безопасность и удобство использования.

Подробнее обо всем этом вы можете почитать в Release Notes.

Недавно мы писали о новых возможностях продукта VMware NSX 4.2, который стал доступен одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware Aria Operations 8.18 для управления и мониторинга виртуального датацентра. Напомним также, что о версии Aria Operations 8.16 мы писали вот тут.

Удаленные коллекторы

VMware Aria Operations 8.14 был последним релизом, поддерживающим удаленные коллекторы. В версиях 8.16 и позднее обновления невозможны при наличии удаленных коллекторов. Для обновления необходимо заменить все удаленные коллекторы на облачные прокси. Это изменение улучшит сбор данных и упростит управление.

Устаревание XML в REST API

В следующем крупном релизе VMware Aria Operations поддержка XML в новых API и новых функциях существующих API будет прекращена. Для обмена данными рекомендуется использовать JSON, хотя текущие API продолжат поддерживать XML.

Поддержка облачных платформ и новых интеграций

Поддержка интеграций с облачными платформами Amazon Web Services, Microsoft Azure, Oracle Cloud VMware Solution и Google Cloud Platform будет доступна только через Marketplace. Важно обновить адаптер Google Cloud Platform до версии 8.18 сразу после обновления кластера, чтобы избежать потери данных.

Улучшенная навигация и управление

Введено новое меню навигации, ориентированное на выполнение задач, и средства для управления стеком VMware Cloud Foundation, включая обновление сертификатов, контроль конфигураций и диагностику. На вкладке Overview на главной странице представлены возможности управления и мониторинга VMware Cloud Foundation.

Диагностика и мониторинг

Теперь можно получать информацию о известных проблемах, влияющих на программное обеспечение VMware, и следить за состоянием ключевых случаев использования VMware Cloud Foundation, таких как vMotion, Snapshots и Workload Provisioning. Введены новые функции для контроля и устранения отклонений конфигураций vCenter.

Единый вход и управление лицензиями

Поддержка единого входа (SSO) для VMware vSphere Foundation с возможностью импорта пользователей и групп из провайдера SSO. Управление лицензиями VMware Cloud Foundation и VMware vSphere Foundation теперь доступно в VMware Aria Operations.

Управление сертификатами

Появилось централизованное управление сертификатами для всех компонентов VMware Cloud Foundation. Также есть и возможность мониторинга и получения информации о сертификатах инфраструктуры VMware Cloud Foundation.

Улучшение пользовательского опыта и отчетности

Обновленный опыт работы с инвентарем и виджетами, поддержка просмотра объектов с предками и потомками, возможность фильтрации по возрасту объектов и определениям предупреждений. Возможность добавления до пяти панелей инструментов на главную страницу и их упорядочивания.

Снижение шума предупреждений и улучшение панели инструментов

Введение 20-секундной пиковой метрики, что позволяет получить более четкую видимость данных и уменьшить шум предупреждений. Обновленные панели инструментов, такие как панель изменений VM и панель производительности кластеров, обеспечивают лучшую видимость и взаимодействие.

Управление емкостью и стоимостью

Возможность переопределения метрик для расчета емкости и получения рекомендаций по оптимизации ресурсов. Управление затратами на лицензии VMware по ядрам, а также доступность метрик затрат для проектов и развертываний VMware Aria Automation.

Миграция Telegraf и усиление безопасности

Поддержка сохранения конфигурации плагинов Telegraf при переустановке и усиление безопасности за счет ограничения входящих сетевых подключений и предотвращения несанкционированного доступа.

Улучшения для vSAN и отчеты о соответствии

Поддержка кластера vSAN Max и улучшения виджетов для отображения информации о предках и потомках объектов. Обновления пакетов соответствия для CIS и DISA, поддержка новых версий ESXI и vSphere.

Эти новые возможности и улучшения делают VMware Aria Operations 8.18 более мощным и удобным инструментом для управления виртуальной инфраструктурой, повышая эффективность и безопасность работы с облачными и локальными ресурсами.

Подробнее обо всем этом вы можете почитать в Release Notes.

Недавно мы писали об использовании устройств DPU в современных датацентрах, сегодня поговорим о новых возможностях поддержки устройств Dual DPU.

В последнем релизе платформ Cloud Foundation 5.2 и vSphere 8.0 Update 3 компания VMware представила новинку - поддержку возможностей устройств Dual DPU. Эта функция предназначена для значительного повышения производительности и обеспечения высокой доступности вашей сетевой инфраструктуры.

Почему поддержка Dual DPU важна

С ростом требований к производительности и надежности сетевой инфраструктуры, поддержка Dual DPU в VMware Cloud Foundation 5.2 дает клиентам надежное решение. Увеличивая пропускную способность вдвое и предоставляя гибкие настройки для производительности или высокой доступности, эта функция отвечает потребностям современных центров обработки данных и частных облачных сред. Независимо от того, стремитесь ли вы улучшить производительность сети или обеспечить резервную мощность для критически важных рабочих нагрузок, поддержка Dual DPU обеспечивает универсальность и надежность, необходимые вам.

Основные особенности поддержки Dual DPU

• Управление несколькими DPU на одном хосте

С поддержкой Dual DPU вы теперь можете управлять двумя экземплярами DPU в пределах одного хоста. Это усовершенствование упрощает процесс управления, гарантируя, что оба модуля DPU эффективно обрабатываются без дополнительных сложностей.

• Повышенная производительность и пропускная способность

Одним из самых значимых преимуществ поддержки Dual DPU является увеличение производительности. Поддерживая два DPU на одном хосте, VMware позволяет удвоить пропускную способность. Каждый DPU работает независимо, но вместе они обеспечивают 2-кратное увеличение пропускной способности.

Гибкость в использовании DPU

Новая конфигурация Dual DPU предлагает клиентам гибкость в использовании их DPU:

1. Производительность: оба DPU работают независимо, обеспечивая максимальную пропускную способность. Эта конфигурация идеальна для сред, где производительность критически важна, так как она полностью использует увеличенную полосу пропускания.
2. Высокая доступность: Клиенты могут настроить DPU в состоянии Active-Standby для повышения отказоустойчивости. В этом режиме, если активный DPU выходит из строя, весь трафик бесшовно переключается на резервный DPU, обеспечивая непрерывность обслуживания. Эта конфигурация идеально подходит для критически важных приложений, где время бесперебойной работы имеет первостепенное значение.

Поддержка VMware vSphere Lifecycle Manager

В VMware vSphere 8 Update 3, vSphere Lifecycle Manager (vLCM) включает поддержку конфигураций с двумя DPU. Как и в случае с одиночными DPU, vLCM будет обеспечивать обновление и поддержание в актуальном состоянии версий ESXi для обоих модулей DPU. Эта интегрированная поддержка упрощает управление жизненным циклом и обеспечивает согласованность в вашей инфраструктуре.

В интересах обеспечения удовлетворенности клиентов, компания VMware решила продлить общий период поддержки (general support) для продуктов VMware vSphere 7.x и VMware vSAN 7.x. Изначально установленная дата окончания общей поддержки (End of General Support, EoGS) была назначена на 2 апреля 2025 года, но теперь она продлена на 6 месяцев, до 2 октября 2025 года.

Это продление общего периода поддержки предоставляет клиентам большую гибкость в планировании будущих обновлений. VMware стремится создать надежную среду поддержки и предоставить достаточно времени для стратегического планирования с учетом изменяющихся потребностей клиентов.

Резюме ключевых дат:

* Применимо к поддержке, приобретенной до 6 мая 2024 года.

Для получения более подробной информации или вопросов, пожалуйста, свяжитесь с вашим представителем VMware, партнером-реселлером Broadcom или службой поддержки VMware.

VMware vSphere давно зарекомендовала себя как одна из ведущих платформ для виртуализации, обеспечивая мощные инструменты для управления виртуальными машинами (VM) и инфраструктурой центров обработки данных (ЦОД). В версии VMware vSphere 8 Update 3 была введена новая важная функция — Live Patch. Это нововведение позволяет администраторам вносить критические исправления и обновления безопасности в ядро гипервизора ESXi без необходимости перезагрузки системы или отключения виртуальных машин. В данной статье мы рассмотрим, что такое Live Patching, его преимущества, технические аспекты работы и потенциальные ограничения.

Выход платформы VMware vSphere 8 переопределил подход к управлению жизненным циклом и обслуживанием инфраструктуры vSphere. Решение vSphere Lifecycle Manager упрощает управление образами кластеров, обеспечивает полный цикл управления драйверами и прошивками, а также ускоряет полное восстановление кластера. Управление сертификатами происходит без сбоев, а обновления vCenter можно выполнять с гораздо меньшими простоями по сравнению с прошлыми релизами платформы.

vSphere 8 Update 3 продолжает эту тенденцию снижения и устранения простоев с введением функции vSphere Live Patch.

vSphere Live Patch позволяет обновлять кластеры vSphere и накатывать патчи без миграции рабочих нагрузок с целевых хостов и без необходимости перевода хостов в полный режим обслуживания. Патч применяется в реальном времени, пока рабочие нагрузки продолжают выполняться.

Требования данной техники:

• vSphere Live Patch является опциональной функцией, которую необходимо активировать перед выполнением задач восстановления.
• vCenter должен быть версии 8.0 Update 3 или выше.
• Хосты ESXi должны быть версии 8.0 Update 3 или выше.
• Настройка Enforce Live Patch должна быть включена в глобальных настройках восстановления vSphere Lifecycle Manager или в настройках восстановления кластера.
• DRS должен быть включен на кластере vSphere и работать в полностью автоматическом режиме.
• Для виртуальных машин с включенной vGPU необходимо активировать Passthrough VM DRS Automation.
• Текущая сборка кластера vSphere должна быть пригодна для применения live-патчинга (подробности ниже).

Как работает Live Patching

Кликните на картинку, чтобы открыть анимацию:

Распишем этот процесс по шагам:

• Хост ESXi переходит в режим частичного обслуживания (partial maintenance mode). Частичный режим обслуживания — это автоматическое состояние, в которое переходит каждый хост. В этом особом состоянии существующие виртуальные машины продолжают работать, но создание новых ВМ на хосте или миграция ВМ на этот хост или с него запрещены.
• Новая версия компонентов целевого патча монтируется параллельно с текущей версией.
• Файлы и процессы обновляются за счет смонтированной версии патча.
• Виртуальные машины проходят быструю паузу и запуск (fast-suspend-resume) для использования обновленной версии компонентов.

Не все патчи одинаковы

Механизм vSphere Live Patch изначально доступен только для определенного типа патчей. Патчи для компонента выполнения виртуальных машин ESXi (virtual machine execution component) являются первыми целями для vSphere Live Patch.

Патчи, которые могут изменить другие области ESXi, например патчи VMkernel, изначально не поддерживаются для vSphere Live Patch и пока требуют следования существующему процессу патчинга, который подразумевает перевод хостов в режим обслуживания и эвакуацию ВМ.

Обновления vSphere Live Patches могут быть установлены только на поддерживаемые совместимые версии ESXi. Каждый Live Patch будет указывать, с какой предыдущей сборкой он совместим. vSphere Lifecycle Manager укажет подходящие версии при определении образа кластера. Также вы можете увидеть подходящую версию в репозитории образов vSphere Lifecycle Manager:

Например, patch 8.0 U3a 23658840 может быть применен только к совместимой версии 8.0 U3 23653650. Системы, которые не работают на совместимой версии, все равно могут быть обновлены, но для этого будет использован существующий процесс "холодных" патчей, требующий перевода хостов в режим обслуживания и эвакуации ВМ.

Соответствие образа кластера будет указывать на возможность использования Live Patch.

Быстрое приостановление и возобновление (fast-suspend-resume)

Как упоминалось ранее, патчи для компонента выполнения виртуальных машин в ESXi являются первой целью для vSphere Live Patch. Это означает, что хотя виртуальные машины не нужно эвакуировать с хоста, им нужно выполнить так называемое быстрое приостановление и возобновление (FSR) для использования обновленной среды выполнения виртуальных машин.

FSR виртуальной машины — это ненарушающее работу действие, которое уже используется в операциях с виртуальными машинами при добавлении или удалении виртуальных аппаратных устройств (Hot Add) в работающие виртуальные машины.

Некоторые виртуальные машины несовместимы с FSR. Виртуальные машины, настроенные с включенной функцией Fault Tolerance, машины, использующие Direct Path I/O, и vSphere Pods не могут использовать FSR и нуждаются в участии администратора. Это может быть выполнено либо путем миграции виртуальной машины, либо путем перезагрузки виртуальной машины.

Сканирование на соответствие в vSphere Lifecycle Manager укажет виртуальные машины, несовместимые с FSR, и причину несовместимости:

После успешного восстановления кластера любые хосты, на которых работают виртуальные машины, не поддерживающие FSR, будут продолжать сообщать о несоответствии требованиям. Виртуальные машины необходимо вручную переместить с помощью vMotion или перезагрузить. Только тогда кластер будет полностью соответствовать требованиям (compliant).

Отметим, что vSphere Live Patch несовместим с системами, работающими с устройствами TPM или DPU, использующими vSphere Distributed Services Engine.

Наверняка вы слышали о недавнем обновлении программного обеспечения CrowdStrike для Microsoft Windows, которое вызвало беспрецедентный глобальный сбой по всему миру (а может даже вы были непосредственно им затронуты). Несколько дней назад ИТ-администраторы работали круглосуточно, чтобы восстановить работоспособность тысяч, если не десятков тысяч систем Windows.

Текущий рекомендуемый процесс восстановления от CrowdStrike определенно болезненный, так как он требует от пользователей перехода в безопасный режим Windows для удаления проблемного файла. Большинство организаций используют Microsoft Bitlocker, что добавляет дополнительный шаг к уже и так болезненному ручному процессу восстановления, так как теперь необходимо найти ключи восстановления перед тем, как войти в систему и применить исправление.

Вильям Лам написал об этой ситуации. В течение нескольких часов после новостей от CrowdStrike он уже увидел ряд запросов от клиентов и сотрудников на предмет наличия автоматизированных решений или скриптов, которые могли бы помочь в их восстановлении, так как требование к любой организации вручную восстанавливать системы неприемлемо из-за масштабов развертываний в большинстве предприятий. Ознакомившись с шагами по восстановлению и размышляя о том, как платформа vSphere может помочь пользователям автоматизировать то, что обычно является ручной задачей, у него возникло несколько идей, которые могут быть полезны.

Скрипты, предоставленные в этой статье, являются примерами. Пожалуйста, тестируйте и адаптируйте их в соответствии с вашей собственной средой, так как они не были протестированы официально, и их поведение может варьироваться в зависимости от среды. Используйте их на свой страх и риск.

Платформа vSphere обладает одной полезной возможностью, которая до сих пор не всем известна, позволяющей пользователям автоматизировать отправку нажатий клавиш в виртуальную машину (VM), что не требует наличия VMware Tools или даже запущенной гостевой операционной системы.

Чтобы продемонстрировать, как может выглядеть автоматизированное решение для устранения проблемы CrowdStrike, Вильям создал прототип PowerCLI-скрипта под названием crowdstrike-example-prototype-remediation-script.ps1, который зависит от функции Set-VMKeystrokes. В настройке автора работает Windows Server 2019 с включенным Bitlocker, и он "смоделировал" директорию и конфигурационный файл CrowdStrike, которые должны быть удалены в рамках процесса восстановления. Вместо загрузки в безопасный режим, что немного сложнее, автор решил просто загрузиться в установщик Windows Server 2019 и перейти в режим восстановления, что позволило ему применить тот же процесс восстановления.

Ниже представлено видео, демонстрирующее автоматизацию и шаги, происходящие между PowerCLI-скриптом и тем, что происходит в консоли виртуальной машины. Вручную никакие действия не выполнялись:

В зависимости от вашей среды и масштаба, вам может потребоваться настроить различные значения задержек, и это следует делать в тестовой или разработческой среде перед развертыванием поэтапно.

В качестве альтернативы, автор также рекомендует и немного другой подход. Один из клиентов создал кастомный WindowsPE ISO, который содержал скрипт для удаления проблемного файла CrowdStrike, и всё, что им нужно было сделать, это смонтировать ISO, изменить порядок загрузки с жесткого диска на CDROM, после чего ISO автоматически выполнил бы процесс восстановления, вместо использования безопасного режима, что является довольно умным решением.

В любом случае, вот пример фрагмента PowerCLI-кода, который реконфигурирует виртуальную машину (поддерживается, когда ВМ выключена) для монтирования нужного ISO из хранилища vSphere и обновляет порядок загрузки так, чтобы машина автоматически загружалась с ISO, а не с жесткого диска.

$vmName = "CrowdStrike-VM"
$isoPath = "[nfs-datastore-synology] ISO/en_windows_server_version_1903_x64_dvd_58ddff4b.iso"
$primaryDisk = "Hard disk 1"

$vm = Get-VM $vmName
$vmDevices = $vm.ExtensionData.Config.Hardware.Device

$cdromDevice = $vmDevices | where {$_.getType().name -eq "VirtualCdrom"}
$bootDevice = $vmDevices | where {$_.getType().name -eq "VirtualDisk" -and $_.DeviceInfo.Label -eq $primaryDisk}

# Configure Boot Order to boot from ISO and then Hard Disk
$cdromBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableCdromDevice
$diskBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableDiskDevice
$diskBootDevice.DeviceKey = $bootDevice.key

$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.bootOrder = @($cdromBootDevice,$diskBootDevice)

# Mount ISO from vSphere Datastore
$cdromBacking = New-Object VMware.Vim.VirtualCdromIsoBackingInfo
$cdromBacking.FileName = $isoPath

$deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec
$deviceChange.operation = "edit"
$deviceChange.device = $cdromDevice
$deviceChange.device.Backing = $cdromBacking
$deviceChange.device.Connectable.StartConnected = $true
$deviceChange.device.Connectable.Connected = $true

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = @($deviceChange)
$spec.bootOptions = $bootOptions

$task = $vm.ExtensionData.ReconfigVM_Task($spec)
$task1 = Get-Task -Id ("Task-$($task.value)")
$task1 | Wait-Task | Out-Null

Чтобы подтвердить, что изменения были успешно применены, вы можете использовать интерфейс vSphere или следующий фрагмент PowerCLI-кода:

$vm = Get-VM $vmName
$vm.ExtensionData.Config.BootOptions | Select BootOrder
$vm | Get-CDDrive | select IsoPath

Остается только запустить виртуальную машину, а затем, после завершения восстановления, можно отменить операцию, размонтировав ISO и удалив конфигурацию порядка загрузки, чтобы вернуть исходное поведение виртуальной машины.

Автор сайта virten.net сделал интересную и полезную страницу, где вы можете отслеживать выход свежих релизов продуктов VMware, включая VMware vSphere / ESXi / vCenter, NSX, Aria и другие. Называется эта штука VMware Product Release Tracker (vTracker):

Ссылки, которые позволят вам это использовать в удобном формате:

• vTracker RSS Feed
• vTracker JSON Export
• vTracker CSV Export
• vTracker Table (новое)

Надо сказать, что информация тут обновляется только про финальные релизы, доступные на сайте Broadcom в режиме General Availability (GA), поэтому если вам нужны бета-версии различных решений - отслеживать их нужно отдельно.

Среди новых возможностей последнего обновления платформы виртуализации VMware vSphere 8 Update 3 появилась интересная новая функция, которая позволяет удалять снапшоты виртуальных машин, которые старше некоторого количества дней, которое задается при выполнении этой операции.

Если же вы хотите более глубокого уровня автоматизации, то вы можете применять политики snapshot retention policies с использованием виртуального модуля VMware Event Broker Appliance (VEBA).

Вы можете объединить эту новую возможность в vSphere 8.0 Update 3 с существующей задачей планирования vSphere (Scheduled Tasks), которая периодически очищает существующие снимки, и администраторы теперь имеют дополнительную возможность для быстрой установки возраста снимка, который нужно удалить, без необходимости создавать или полагаться на пользовательский скрипт, который должен быть создан вне сервера vCenter.

Хотя это может показаться незначительной функцией, она определенно улучшает управление операциями для администраторов, позволяя им гарантировать оптимальную работу и не беспокоиться о том, что снимок виртуальной машины сохранится дольше, чем это требуется по политикам.

Среди новых возможностей VMware vSphere 8 Update 3 было улучшение механизма быстрого обновления vCenter Reduced Downtime (анонсирован он был еще в vSphere 8 Update 2). Сегодня мы рассмотрим его подробнее.

Обновление с сокращением времени простоя (Reduced Downtime Update, RDU) использует метод миграции для перехода с одной сборки vCenter на более новую сборку vCenter. Это похоже на существующий метод выполнения крупного обновления vCenter, например, с версии 7 на версию 8, но имеет значительное отличие.

При использовании метода на основе миграции, развертывается новый виртуальный модуль vCenter, и все данные и конфигурации vCenter копируются с текущего vCenter на новый экземпляр последней версии. Основное отличие заключается в том, что во время этой фазы копирования данных и конфигурации текущий vCenter и все его службы остаются онлайн, и vCenter может продолжать свою работу. При этом время простоя службы vCenter составляет всего несколько минут, в этот промежуток текущие службы vCenter останавливаются, а новые службы vCenter запускаются. Обычно это занимает менее 5 минут.

Обновление vCenter с сокращением времени простоя можно использовать для обновления любой версии и топологии vCenter 8 до версии 8 Update 3 или более поздней.

Что нового в vSphere 8 Update 3 для RDU?

Новая поддержка топологий

В vSphere 8 Update 3, обновление vCenter с сокращением времени простоя поддерживает все топологии развертывания vCenter:

• Self-managed: ВМ vCenter управляется самостоятельно.
• Non self-managed: ВМ vCenter управляется другим vCenter (должен быть версии 7.0 или более поздней).
• Связанный режим (Enhanced Linked Mode): два или более экземпляра vCenter, участвующие в одном домене SSO. Не обновляйте несколько экземпляров vCenter параллельно, если они связаны через Enhanced Linked Mode.
• vCenter HA: экземпляры vCenter, настроенные для высокой доступности.
  • vCenter HA автоматически удаляется перед началом обновления и автоматически реактивируется после завершения обновления.
  • Обе топологии self-managed и non self-managed для vCenter HA поддерживаются для обновления с сокращением времени простоя.
  • Экземпляры vCenter HA должны быть как минимум версии vCenter 8 Update 2, чтобы позволить обновлению RDU координировать операцию. Для версий ранее vCenter 8 Update 2, вы можете вручную деактивировать vCenter HA, использовать обновление RDU и вручную реактивировать vCenter HA.

Вам не нужно сначала обновляться до vCenter 8 Update 3, чтобы начать использовать обновление RDU. Вы можете использовать обновление с сокращением времени простоя для вышеуказанных топологий, чтобы обновить экземпляры vCenter, работающие на версии 8.0 и более поздних, до версии 8.0 Update 3 и более поздних. Например, вы можете использовать обновление с сокращением времени простоя, чтобы обновить vCenter 8 Update 1 в режиме Enhanced Linked Mode до vCenter 8 Update 3.

Автоматическое переключение

У вас есть новая опция для автоматического завершения фазы переключения, либо вы можете вручную инициировать фазу переключения.

Дункан Эппинг опубликовал интересный пост, касающийся изменений в интерфейсе vSAN Data Protection, произошедших в новой версии пакета обновлений VMware vSphere 8 Update 3.

Впервые развернув vSphere/vSAN 8.0 U3, он сразу же начал искать интерфейс vSAN Data Protection. Он не смог его найти, но подумал, что это из-за использования какой-то странной альфа-версии продукта. Теперь, когда продукт вышел, эта функция должна быть доступна из коробки, верно?

Нет, не так. Вам нужно развернуть виртуальный модуль (Virtual Appliance), чтобы эта функция появилась в интерфейсе. Этот модуль можно найти в разделе «Drivers and Tools» в разделе загрузок vSphere Hypervisor, который находится по основными ссылками на дистрибутивы vSphere. Он называется «VMware vSAN Snapshot Service Appliance». Текущая версия называется «snapservice_appliance-8.0.3.0-24057802_OVF10.ova». Вам нужно развернуть этот OVA, при это настоятельно рекомендуется запросить для него DNS-имя и правильно зарегистрировать его. Автор возился с файлом hosts на VCSA и забыл добавить имя в локальный файл hosts на своем ноутбуке, из-за чего возникли странные проблемы.

Еще одна вещь, на которую стоит обратить внимание: документация предлагает загрузить сертификаты и скопировать текст для модуля. Это не то, что большинство из нас делает ежедневно. Вы можете просто открыть веб-браузер и использовать следующий URL «https://<имя вашего сервера vCenter>/certs/download.zip», чтобы загрузить сертификаты, а затем распаковать загруженный файл. Более подробную информацию можно найти здесь.

Внутри будут сертификаты, и если вы откроете сертификат в подходящем текстовом редакторе, вы сможете скопировать/вставить его в экран развертывания для OVA.

Теперь, когда вы развернули OVA и все правильно настроено, вы должны увидеть успешное выполнение задачи, а точнее две: загрузка плагина и развертывание плагина, как показано на следующем скриншоте.

Если вы получите сообщение об ошибке «error downloading plug-in», вероятно, это связано с одной из двух причин:

• Файлы DNS / Hosts настроены некорректно, в результате чего URL недоступен. Убедитесь, что вы можете разрешить URL.
• Отпечаток (thumbprint) сертификата был неправильно скопирован/вставлен. Здесь есть целый раздел по устранению этой проблемы.

Недавно мы писали о новых возможностях пакета обновлений платформы виртуализации VMware vSphere 8 Update 3. Сегодня мы более детально рассмотрим, что нового там появилось в плане поддержки карт GPU.

Новые функции охватывают несколько областей, начиная с использования vGPU-профилей разных типов и размеров вместе и заканчивая внесением изменений в расширенные параметры DRS, которые определяют, как ВМ с поддержкой vGPU будет обрабатываться со стороны vMotion, например. Все эти улучшения направлены на упрощение жизни системных администраторов, дата-сайентистов и других пользователей, чтобы они могли использовать свои рабочие нагрузки на платформах vSphere и VCF.

Гетерогенные типы vGPU-профилей с разными размерами

В VMware vSphere мы можем назначить машине vGPU-профиль из набора заранее определенных профилей, чтобы предоставить ей определенную функциональность. Набор доступных vGPU-профилей появляется после установки NVIDIA vGPU менеджера/драйвера на уровне хоста в ESXi посредством vSphere Installation Bundle (VIB).

Эти vGPU-профили называются профилями типа C в случае, если профиль предназначен для интенсивной вычислительной работы, такой как обучение моделей машинного обучения. Существуют и несколько других типов vGPU-профилей, среди которых Q (Quadro) для графических рабочих нагрузок являются одними из самых популярных. Буквы «c» и «q» стоят в конце названия vGPU-профиля, отсюда и название этого типа.

В предыдущем обновлении vSphere 8 Update 2 мы могли назначать машине vGPU-профили, которые предоставляли поддержку различных видов функциональности, используя при этом одно и то же устройство GPU. Ограничением в этой версии vSphere было то, что они должны были быть vGPU-профилями одного и того же размера, например, те, которые заканчиваются на 8q и 8c. Здесь «8» представляет количество гигабайт памяти на самом GPU (иногда называемой framebuffer-памятью), которая назначена ВМ, использующей этот vGPU-профиль. Это значение может изменяться в зависимости от модели основного GPU.

При использовании GPU A40 или L40s мы можем иметь vGPU-профиль типа C, предназначенный для вычислительно интенсивной работы, такой как машинное обучение, и vGPU-профиль типа Q (предназначенный для графической работы), назначенные разным ВМ, которые делят один и тот же физический GPU на хосте.

Теперь в vSphere 8 Update 3 можно продолжать смешивать эти разные типы vGPU-профилей на одном физическом GPU, а также иметь vGPU-профили разного размера памяти, которые делят один и тот же GPU.

В качестве примера новой функциональности vSphere 8 Update 3: ВМ1 с vGPU-профилем l40-16c (для вычислительных нагрузок) и ВМ2 с vGPU-профилем l40-12q (для графических нагрузок) делят одно и то же устройство L40 GPU внутри хоста. Фактически, все вышеупомянутые виртуальные машины делят одно и то же физическое устройство L40 GPU.

Это позволяет лучше консолидировать рабочие нагрузки на меньшее количество GPU, когда рабочие нагрузки не потребляют весь GPU целиком. Возможность размещения гетерогенных типов и размеров vGPU-профилей на одном устройстве GPU применяется к GPU L40, L40s и A40 в частности, так как эти GPU имеют двойное назначение. То есть они могут обрабатывать как графические, так и вычислительно интенсивные задачи, в то время как GPU H100 предназначен исключительно для вычислительно интенсивных задач.

Включение настроек кластера для DRS и мобильности ВМ с vGPU

В vSphere Client версии 8.0 U3 появились новые настройки кластера, которые предоставляют более удобный метод настройки расширенных параметров для кластера DRS. Вы можете установить ограничение по времени приостановки ВМ, которое будет допускаться для машин с vGPU-профилями, которым может потребоваться больше времени, чем по умолчанию, для выполнения vMotion. Время приостановки по умолчанию для vMotion составляет 100 секунд, но этого может быть недостаточно для некоторых ВМ с большими vGPU-профилями. Дополнительное время требуется для копирования памяти GPU на целевой хост. Вы также можете узнать оценочное время приостановки для вашей конкретной ВМ с поддержкой vGPU в vSphere Client. Для получения дополнительной информации о времени приостановки, пожалуйста, ознакомьтесь с этой статьей.

В vSphere 8 Update 3 появился более удобный пользовательский интерфейс для настройки расширенных параметров для кластера DRS, связанных с vMotion виртуальных машин.

Прежде чем мы рассмотрим второй выделенный элемент на экране редактирования настроек кластера ниже, важно понять, что vGPU как механизм доступа к GPU является одной из множества техник, которые находятся в "спектре проброса устройств" (Passthrough spectrum). То есть, vGPU на самом деле является одной из форм прямого доступа. Возможно, вы считали, что подходы прямого проброса и vGPU сильно отличаются друг от друга до настоящего времени, так как они действительно разделены в vSphere Client при выборе добавления нового PCIe-устройства к ВМ. Однако, они тесно связаны друг с другом. Фактически, vGPU ранее назывался "опосредованным пробросом" (mediated passthrough). Этот спектр использования прямого доступа различными способами показан здесь.

Именно поэтому в vSphere Client на выделенном участке экрана ниже используются термины «Passthrough VM» и «Passthrough Devices». Эти термины на самом деле относятся к виртуальным машинам с поддержкой vGPU – и таким образом, обсуждение касается включения DRS и vMotion для виртуальных машин с поддержкой vGPU на этом экране. vMotion не разрешен для виртуальных машин, использующих фиксированный прямой доступ, как показано на левой стороне диаграммы выше.

Новая функция интерфейса позволяет пользователю включить расширенную настройку vSphere под названием «PassthroughDrsAutomation». С включенной этой настройкой, при соблюдении правил по времени приостановки, виртуальные машины в этом кластере могут быть перемещены vMotion на другой хост по решению DRS. Для получения дополнительной информации об этих расширенных настройках DRS, пожалуйста, ознакомьтесь с этой статьей.

Доступ к медиа-движку GPU

Единый медиа-движок на GPU может использоваться виртуальной машиной, которая хостит приложение, которому требуется выполнять транскодирование (кодирование/декодирование) на GPU, а не на более медленном CPU, например, для видео-приложений.

В vSphere 8 Update 3 поддерживается новый vGPU-профиль для виртуальных машин, которым требуется доступ к медиа-движку внутри GPU. Только одна виртуальная машина может использовать этот медиа-движок. Примеры таких vGPU-профилей («me» означает media engine):

• a100-1-5cme (один срез)
• h100-1-10cme (два среза)

Более высокая скорость vMotion виртуальных машин с большими vGPU-профилями

Новые улучшения в vMotion позволяют нам увеличивать пропускную способность для сети vMotion со скоростью 100 Гбит/с до 60 Гбит/с для vMotion виртуальной машины, к которой подключен современный GPU (H100, L40S), что сокращает время vMotion. Это не относится к GPU A100 и A30, которые относятся к более старой архитектуре (GA100).

Новые технические документы и рекомендации по проектированию GPU с VMware Private AI Foundation with NVIDIA

Недавно были выпущены два важных публикации авторами VMware. Агустин Маланко Лейва и команда опубликовали решение VMware Validation Solution для инфраструктуры Private AI Ready Infrastructure, доступное здесь.

Этот документ предоставляет подробное руководство по настройке GPU/vGPU на VMware Cloud Foundation и многим другим факторам для организации вашей инфраструктуры для развертывания VMware Private AI.

Одним из ключевых приложений, которое будут развертывать в первую очередь в инфраструктуре VMware Private AI Foundation с NVIDIA, является генерация с дополненным извлечением или RAG. Фрэнк Деннеман и Крис МакКейн подробно рассматривают требования к безопасности и конфиденциальности и детали реализации этого в новом техническом документе под названием VMware Private AI – Privacy and Security Best Practices.

Недавно мы писали о новых возможностях обновленной версии платформы VMware vSphere 8.0 Update 3, а также о том, что нового появилось в плане основных функций хранилищ (Core Storage). Сегодня мы расскажем о новой версии решения VMware vSphere IaaS Control Plane 8.0.

Для начала - что это за решение? VMware внедрила декларативный API в vSphere, чтобы обеспечить современный опыт IaaS для потребителей облачных услуг. Решение vSphere IaaS Control Plane основывается на работе, проделанной в рамках инициативы vSphere with Tanzu, и расширяет её новым набором возможностей IaaS.

Давайте посмотрим, что нового появилось с выпуском vSphere 8 Update 3.

Независимая служба TKG Service

VMware представляет независимую службу TKG Service, которая отделена от vCenter и реализована как основная служба Supervisor Service. Это позволит выпускать асинхронные обновления сервиса и предоставлять новые версии Kubernetes быстрее, чем когда-либо.

Администраторы смогут обновлять TKG Service без необходимости обновлять Supervisor или vCenter, чтобы без проблем получать и использовать новые версии Kubernetes. Эти версии затем могут быть использованы непосредственно потребителями услуг.

Local Consumption Interface (LCI)

Интерфейс потребления облака (Cloud Consumption Interface, CCI) в Aria Automation предоставляет пользовательский интерфейс для создания виртуальных машин, кластеров TKG, балансировщиков нагрузки и запросов постоянных томов (Persistent Volume Claims).

Этот интерфейс теперь доступен в vCenter для каждого отдельного пространства имен. Пользовательский интерфейс поддерживает сложные спецификации для виртуальных машин и кластеров TKG, автоматически генерируя YAML для пользователей, которые хотят взаимодействовать с API напрямую. Интерфейс виртуальной машины поддерживает создание секретов и configmap для хранения конфигурации облака для настройки экземпляра виртуальной машины. Мастер создания кластеров расширен для поддержки сложных типов кластеров, которые могут включать смешанные рабочие узлы с конфигурациями GPU и без GPU.

Автомасштабирование для кластеров Kubernetes

VMware представила автоматическое масштабирование для кластеров Kubernetes с использованием Cluster Autoscaler. Это позволит кластерам Kubernetes соответствовать текущим потребностям, уменьшать количество узлов при низкой загрузке и увеличивать их количество при росте запросов. Рабочие узлы будут автоматически добавляться, когда ресурсов недостаточно для выполнения планирования подов.

Cluster Autoscaler может быть установлен как стандартный пакет с использованием kubectl или tanzu cli. Версия пакета должна соответствовать минорным версиям Kubernetes, например, чтобы установить пакет на кластер Kubernetes версии v1.26.5, необходимо установить пакет Cluster Autoscaler версии v1.26.2.

Минимально требуемая версия для Cluster Autoscaler — v1.25.

Поддержка растянутых кластеров vSAN Stretched Cluster

Одной из самых востребованных опций конфигурации была возможность развертывания Supervisor на растянутом кластере vSAN, охватывающем два физических местоположения или сайта. В этом релизе VMware учла основные требования для поддержки этой реализации, однако есть некоторые моменты, которые следует учитывать.

Основное внимание следует уделить доступности etcd, который является основной базой данных, хранящей все данные кластера Kubernetes. Etcd использует механизм кворума, что означает, что для его работы необходимо, чтобы более половины реплик были доступны в любое время. Поэтому нет смысла распределять нечетное количество виртуальных машин с Control Pane (CP) по двум сайтам. Вместо этого, для развертывания Active/Active, VMware рекомендует:

• Три виртуальные машины CP Supervisor (SV CP) должны быть размещены на одном сайте, при этом этот сайт может быть любым из двух, поскольку оба сайта активны.
• Все виртуальные машины CP любого кластера TKG должны быть размещены на одном сайте, который может быть любым из двух.

Чтобы контролировать размещение, администратору необходимо настроить правила Affinity rules VM-host для каждого набора связанных виртуальных машин, чтобы привязать виртуальную машину к определенному сайту.

Администраторы также должны создать политику растянутого кластера vSAN с определенными настройками, такими как толерантность к сбоям сайта, установленная на двойное зеркалирование сайта, и включенное принудительное предоставление ресурсов. Поскольку политика растянутого кластера vSAN является требованием для библиотек контента и самого Supervisor, сначала необходимо включить растянутый кластер vSAN, а затем уже Supervisor.

Из-за сложности этой архитектуры VMware настоятельно рекомендует следовать документации по передовым методикам, которая есть для этого случая.

Автоматическая ротация сертификатов Supervisor

Еще одна новая функция, которую VMware добавила в этом выпуске, — автоматическая ротация сертификатов Supervisor. По умолчанию сертификаты Supervisor действительны в течение года после первоначального развертывания. Ранее клиенты могли заменять сертификаты, выполняя ряд ручных шагов. Чтобы упростить этот процесс, его автоматизировали, и сертификаты будут просто заменяться по мере приближения их срока истечения без вмешательства пользователя.

Аларм сработает только в случае, если процесс автоматического обновления не удастся, и это будет видно в интерфейсе vCenter. По умолчанию процесс попытается обновить сертификат снова через 12 часов. Как только замена будет успешной, алерт исчезнет.

Пользователи также могут решить заменить сертификат вручную.

Расширенная конфигурация класса виртуальных машин (VM Class Expanded Configuration)

Пользовательский интерфейс класса виртуальных машин (VM Class) в vCenter был обновлен для поддержки значительно расширенного набора опций конфигурации оборудования. Перемещение конфигурации оборудования в класс виртуальных машин (VM Class) упрощает файл спецификации виртуальной машины, позволяя пользователям ссылаться на один класс виртуальной машины как на шаблон для полной спецификации, а не настраивать отдельные параметры напрямую.

Теперь администраторы имеют детальный контроль над конфигурацией оборудования, доступной для пользователей среды самообслуживания. Конфигурация оборудования более точно соответствует моделям потребления в публичных облаках.

Резервное копирование и восстановление кластера

Velero теперь является основным сервисом, включенным в Supervisor. Этот сервис координирует резервное копирование и восстановление как кластера Supervisor, так и любых развернутых кластеров TKG. Velero необходимо устанавливать на отдельные кластеры TKG через CLI. Резервное копирование и восстановление также выполняются через CLI. Резервное копирование и восстановление Supervisor осуществляется через интерфейс vCenter.

Сервис виртуальных машин (VM Service) – резервное копирование и восстановление виртуальных машин

Служба VM Service теперь включает возможность резервного копирования и восстановления виртуальных машин с использованием любого программного обеспечения VMware Advanced Data Protection. Этот метод не требует изменений в вашем инструменте резервного копирования или специальной конфигурации. Резервное копирование можно выполнять на уровне виртуальных машин или для всего пространства имен. Для пространства имен вы просто указываете пул ресурсов, который поддерживает пространство имен в vCenter.

Когда виртуальная машина развертывается с использованием VM Service, в Supervisor создаются объекты пользовательских ресурсов, которые определяют состояние виртуальных машин, а также поддерживающих объектов, которые облегчают начальную настройку виртуальной машины. Эти метаданные должны быть восстановлены как часть процесса резервного копирования/восстановления.

Виртуальные машины, развернутые с использованием VM Service, теперь сохраняют в полях Extra-Config всю информацию, необходимую для воссоздания метаданных Supervisor. Этот процесс регистрации автоматический и происходит при восстановлении. Если автоматическая регистрация по какой-либо причине не удается, например, из-за отсутствия политики хранения или класса виртуальных машин, доступен API для ручного запуска регистрации после устранения проблемы.

Недавно мы писали о выходе большого обновления VMware vSphere 8 Update 3, а несколько дней назад пользователи стали сталкиваться с ошибкой при попытке наката обновления. Текст ошибки выглядит так:

Pre-install failed for vmidentity:Expand

Выглядит это как-то так (только вместо vpxd написано vmidentity):

При этом некоторые пользователи могут откатиться (Rollback) к исходному дистрибутиву, а у кого-то этот селектор неактивен (загреен). При обращении в техподдержку VMware пользователям было сказано, что на эту тему готовится KB, а пока можно воспользоваться приведенным ниже воркэраундом.

Проблема связана с некорневым сертификатом с псевдонимом ssoserver. В VMware есть внутренний документ по этой проблеме, но он пока не доступен публично. Вот шаги, которые VMware предоставляет для исправления:

1. Подключитесь по SSH к серверу vCenter

2. Выведите список сертификатов и определите псевдоним некорневого (Non-CA) сертификата с CN=ssoserver

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

3. Сделайте резервную копию сертификата, который показывает CN=ssoserver
Примечание: замените <Alias> на идентификатор псевдонима, определенный на предыдущем шаге.

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store TRUSTED_ROOTS --alias <Alias> --output /var/tmp/non_ca_ssoserver.crt

4. Удалите сертификат из хранилища VECS.
Примечание: замените <Alias> на идентификатор псевдонима, определенный на шаге 2

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <Alias> -y

5. Повторно выведите список сертификатов и убедитесь, что сертификат удален

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

Теперь можно продолжить обновление vCenter.

Правда у некоторых пользователей после удаления сертификата возникает ошибка, и неясно, нужно ли вручную восстанавливать сертификат после наката обновления. Ждем разъяснений VMware на эту тему.

Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).

Каждое обновление vSphere 8 добавляет множество возможностей для повышения масштабируемости, устойчивости и производительности. В vSphere 8 Update 3 продолжили улучшать и дорабатывать технологию vVols, добавляя новые функции.

Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.

Ключевые улучшения

• Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
• Новая спецификация vVols VASA 6
• Кластеризация VMDK для NVMe/TCP
• Ограничение максимального количества хостов, выполняющих Unmap
• Поддержка NFS 4.1 Port Binding и nConnect
• Дополнительная поддержка CNS/CSI для vSAN

vVols

Поддержка растянутого кластера хранилища vVols на SCSI

Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.

Почему это заняло так много времени?

Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.

Сценарии отказа и восстановления

• Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
• PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
• Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.

Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.

Требования

• Хранилище SCSI (FC или iSCSI)
• Макс. время отклика между хостами vSphere — 11 мс
• Макс. время отклика массива хранения — 11 мс
• Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
• Один vCenter (vCenter HA не поддерживается с vVols)
• Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC

Дополнительная поддержка UNMAP

Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.

Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.

Возврат пространства в хранилищах виртуальных томов vSphere описан тут.

Кликните на картинку, чтобы посмотреть анимацию:

Поддержка кластеризации приложений на NVMe-oF vVols

В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.

Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.

Обновление отчетности по аутентификации хостов для VASA Provider

Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.

Гранулярность хостов Storage Provider для vVols

С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.

NVMe-oF

Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP

В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.

Поддержка NVMe Cross Namespace Copy

В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.

Кликните на картинку, чтобы посмотреть анимацию:

VMFS

Сокращение времени на расширение EZT дисков на VMFS

В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.

Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.

Кликните на картинку для просмотра анимации:

Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore

В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.

Кликните на картинку для просмотра анимации:

По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.

См. статью Space Reclamation on vSphere VMFS Datastores.

Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>

Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:

PSA

Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)

VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.

Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.

Кликните на картинку, чтобы посмотреть анимацию:

NFS

Привязка порта NFS v4.1 к vmk

Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.

См. статью "Настройка привязки VMkernel для хранилища данных NFS 4.1 на хосте ESXi".

Поддержка nConnect для NFS v4.1

Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.

При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:

esxcli storage nfs41 add -H <host> -v <volume-label> -s <remote_share> -c <number_of_connections>

Максимальное количество соединений на сессию по умолчанию ограничено "4", однако его можно увеличить до "8" с помощью продвинутого параметра NFS:

esxcfg-advcfg -s 8 /NFS41/MaxNConnectConns
esxcfg-advcfg -g /NFS41/MaxNConnectConns

Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.

Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:

esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>


Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.

esxcli storage nfs41 add -H <IP1,IP2> -v <volume-label> -s <remote_share> -c <number_of_connections>

Кликните на картинку, чтобы посмотреть анимацию:

CNS/CSI

Поддержка 250 файловых томов для vSAN ESA

В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).

Поддержка файловых томов в топологии HCI Mesh в одном vCenter

Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.

Поддержка CNS на TKGs на растянутом кластере vSAN

Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.

Миграция PV между несвязанными datastore в одном VC

Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.

Поддержка CNS на vSAN Max

Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.

На днях компания VMware в составе Broadcom выпустила очередной пакет обновлений своей флагманской платформы виртуализации - VMware vSphere 8.0 Update 3. vSphere 8 Update 3 улучшает управление жизненным циклом, безопасность и производительность, включая поддержку двойных DPU и улучшенную настройку виртуального оборудования.

Калькулятор лицензий для VCF, VVF и vSAN позволяет вводить данные о примерных конфигурациях виртуальной среды для проведения различных симуляций с целью определения необходимых подписных лицензий для VCF, VVF и vSAN. Более подробная информация об этом процессе изложена в KB 96426.

Не так давно VMware создала калькулятор лицензий, чтобы пользователи могли ознакомиться с новым упрощённым портфелем подписок (напомним, что perpetual лицензий больше нет) для решений с VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF) и VMware vSAN. Этот калькулятор можно использовать для симуляции различных сценариев лицензирования. Перед использованием калькулятора обратитесь к статье базы знаний KB 95727, чтобы узнать основы и принципы лицензирования продуктов VCF, VVF и vSAN.

Как использовать калькулятор лицензий

Необходимые условия:

Загрузите вложения к статье KB, извлеките CSV-файл шаблона и скрипт. Скрипт принимает файл CSV, который представляет собой исходный файл для ввода данных различных конфигураций при проведении симуляций.

При использовании шаблона CSV, пожалуйста, учтите следующие правила:

1. Не переименовывайте колонку ID, так как на неё ссылается скрипт.
2. Каждая строка представляет собой отдельный кластер vSphere и/или vSAN.

Введите данные для каждого из идентификаторов колонок по порядку в каждой строке. Описания идентификаторов колонок и примеры данных приведены в таблице ниже.

Инструкции по использованию калькулятора VCF/VVF

# Подключите исходную функцию

. ./vcf-vvf-calculator.ps1

# Пример использования калькулятора для VCF

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VCF

# Пример использования калькулятора для VVF

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VCF

# Пример использования калькулятора для VCF и экспорт результатов в CSV

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VCF - Csv

# Пример использования калькулятора для VVF и экспорт результатов в CSV

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VVF - Csv

Пример вывода

Вот пример вывода после использования калькулятора лицензий для VVF и vSAN. Обратите внимание, что внизу вывода указано общее количество требуемых лицензий на ядра VVF и TiB vSAN.

В таблице ниже описаны все колонки в разделах VVF/VCF Compute и vSAN:

Загрузить калькулятор лицензий VMware Cloud Foundation, VMware vSphere Foundation и VMware vSAN можно по этой ссылке.

Решение VMware Cloud Foundation Instance Recovery предоставляет собой руководство по восстановлению экземпляра VMware Cloud Foundation (VCF) с нуля до полностью работоспособной среды. Процесс включает подробные инструкции по восстановлению всего экземпляра VCF, включая управляющий домен и домены рабочей нагрузки VI, где необходимо восстановить все компоненты.

Руководство предлагает пошаговые инструкции для ручного восстановления вашего экземпляра VMware Cloud Foundation, а также комплексную автоматизацию в виде модуля PowerShell, чтобы ускорить и упростить процесс ручного восстановления, используя данные из инвентаря VCF SDDC Manager для реконструкции конфигураций. Это устраняет необходимость обращаться к документации, которая может быстро устареть в условиях постоянно меняющегося и сложного программно-определяемого центра обработки данных.

Сценарии использования

Примеры сценариев, когда вам может понадобиться этот процесс:

• Полный сбой площадки
• Восстановление после атаки вредоносного ПО или вымогателей (Ransomware)
• Катастрофическая логическая порча данных

Это особенно важно для отраслей, которые должны соблюдать нормативные требования (такие как Акт о цифровой операционной устойчивости (DORA) в Европейском Союзе).

Немного о DORA

DORA — это регламент Европейского Союза (ЕС), вступивший в силу 16 января 2023 года, который создал обязательную, всеобъемлющую систему управления рисками информационных и коммуникационных технологий (ИКТ) для финансового сектора ЕС.

DORA устанавливает технические стандарты, которые финансовые учреждения и их критически важные поставщики технологий третьих сторон должны внедрить в свои ИКТ системы до 17 января 2025 года.

Организации также должны разработать планы обеспечения непрерывности бизнеса и восстановления после аварий для различных сценариев киберрисков, таких как сбои ИКТ-услуг, природные катастрофы и кибератаки. Эти планы должны включать меры по резервному копированию и восстановлению данных, а также процессы восстановления систем.

Хотя DORA является европейским регламентом, его действия распространяются на компании, работающие в ЕС, независимо от места нахождения их штаб-квартиры. Более того, DORA является примером регламента, который станет более распространенным в других юрисдикциях в ближайшие годы.

Восстановление экземпляра VCF — это не просто на бумаге

Регламенты возлагают на предприятия, такие как финансовые учреждения и связанные с ними поставщики технологий третьих сторон, серьезные обязательства по разработке надежных планов реагирования на сбои их систем.

Организации должны будут проводить периодическое тестирование своих планов, инструментов и систем, чтобы продемонстрировать способность восстанавливать критически важную инфраструктуру в случае сбоев в своевременной и повторяемой манере.

Краткое описание решения

Решение VMware Cloud Foundation Instance Recovery использует комбинацию процессов восстановления из бэкапов, восстановления работоспособности и ребилда данных для воссоздания экземпляра VCF с точно такой же конфигурацией, даже если было утрачено основное оборудование и центр обработки данных, в котором он находился.

• Перестройка/ребилд хостов VMware vSphere с использованием того же или нового оборудования на основе данных, извлеченных из резервной копии инвентаря VCF SDDC Manager
• Выполнение частичного развертывания VCF
• Восстановление экземпляров VMware vCenter и NSX Manager, а также SDDC Manager
• Реконструкция кластеров vSphere, включая их сетевые конфигурации и настройки
• Восстановление NSX Edges
• Восстановление рабочих нагрузок (виртуальных машин)
• Восстановление настроек рабочих нагрузок (группы DRS, теги vSphere и местоположения инвентаря)

Временная шкала восстановления VMware Cloud Foundation Instance Recovery

Чтобы минимизировать время общего восстановления в VMware Cloud Foundation, задачи восстановления могут выполняться в нескольких доменах рабочих нагрузок по перекрывающемуся графику, адаптированному под требования клиентов. Временная шкала предназначена для следующего примера конфигурации:

• 3 домена рабочих нагрузок VI
• Домен VI 1 и домен VI 2 находятся в том же домене единого входа vCenter SSO, что и домен управления. Они находятся в режиме расширенной связи (Enhanced Link Mode, ELM).
• Используется только версия VMware Cloud Foundation 5.x. Домен VI 3 находится в изолированном домене единого входа vCenter (SSO).
• Шаблон восстановления для домена рабочих нагрузок VI в том же домене SSO можно расширить, если к домену управления vCenter подключены дополнительные домены рабочих нагрузок VI.

Автоматизация с помощью PowerShell

Автоматизация представлена в виде модуля PowerShell под названием VMware.CloudFoundation.InstanceRecovery, являющимся комплексным набором командлетов, который упрощает рутинные процессы и уменьшает вероятность ошибок в процессе реконструкции потенциально сложного и большого программно-определяемого центра обработки данных.

Это особенно полезно в случаях, когда задачи выполняются многократно, например, для каждого хоста ESXi или для каждой восстанавливаемой виртуальной машины.

Процесс полагается на способность извлекать данные из резервной копии менеджера SDDC, которую вы собираетесь восстановить. Это означает, что автоматизация может восстановить последнюю жизнеспособную резервную копию без необходимости полагаться на актуальность ручных процессов и документации.

Пример извлечения данных конфигурации из резервной копии менеджера SDDC для использования при восстановлении:

После извлечения каждый шаг процесса использует эти данные для контроля и автоматизации реконструкции.

В лабораторных условиях полные экземпляры VCF, включая домен управления и домены рабочих нагрузок VI, были восстановлены всего за два часа. Многие задачи для дополнительных доменов рабочих нагрузок можно выполнять параллельно или в пересекающемся режиме, чтобы минимизировать общее время восстановления экземпляра.

Это уже было протестировано в лабораторной среде одним из крупнейших клиентов VCF, и они очень рады тому, что это решение предлагает им в плане соблюдения нормативных требований.

У Broadcom есть планы по дальнейшему расширению автоматизации и процессов для поддержки дополнительных топологий, конфигураций и технологий, так что следите за обновлениями!

Недавно Дункан Эппинг выступал с докладом на конференции VMUG в Бельгии, где была тема «Инновации в VMware от Broadcom». В ходе доклада он кратко изложил процесс и различные типы инноваций, а также то, к чему это может привести. Во время сессии он рассмотрел три проекта, а именно vSAN ESA, Distributed Services Engine и проект, над которым сейчас работают, под названием Memory Tiering.

Memory Tiering — это очень интересная концепция, которая впервые была публично представлена на конференции VMware Explore несколько лет назад как потенциальная будущая фича гипервизора. Вы можете задаться вопросом, зачем кому-то захочется ранжировать память, ведь влияние этого процесса на производительность может быть значительным. Существует несколько причин для этого, одна из которых — стоимость памяти. Еще одна проблема, с которой сталкивается индустрия, заключается в том, что емкость (и производительность) памяти не росли такими же темпами, как емкость CPU, что привело к тому, что во многих средах память стала узким местом. Иными словами, дисбаланс между процессором и памятью значительно увеличился. Именно поэтому VMware запустила проект Capitola.

Когда обсуждался проект Capitola, большинство внимания было уделено Intel Optane, и большинство интересующихся знает, что с этим случилось. Некоторые думали, что это также приведет к закрытию проекта Capitola, а также технологий ранжирования и объединения памяти. Но это совершенно не так: VMware продолжает активно работать над проектом и публично обсуждает прогресс, хотя нужно знать, где искать эту информацию. Если вы посмотрите эту сессию, станет ясно, что существует множество усилий, которые позволят клиентам ранжировать память различными способами, одним из которых, конечно, являются различные решения на базе CXL, которые скоро появятся на рынке.

Один из способов — это Memory Tiering с помощью карты ускорителя CXL, по сути, это FPGA, предназначенная исключительно для увеличения емкости памяти, аппаратной разгрузки техник ранжирования памяти и ускорения определенных функций, где память имеет ключевое значение, таких как, например, vMotion. Как упоминалось в сессии SNIA, использование карты ускорителя может привести к сокращению времени миграции на 30%. Такая карта ускорителя также открывает другие возможности, например, memory pooling, чего клиенты просили с тех пор, как в VMware создали концепцию кластера.

Также это открывает возможности совместного использования вычислительных ресурсов между хостами. Только представьте, ваша виртуальная машина может использовать емкость памяти, доступную на другом хосте, без необходимости перемещать саму виртуальную машину. Понятное дело, что это может оказать значительное влияние на производительность.

Именно здесь вступают в игру технологии VMware. На VMworld в 2021 году, когда был представлен проект Capitola, команда VMware также поделилась результатами последних тестов производительности, и было показано, что снижение производительности составило около 10% при использовании 50% оперативной памяти (DRAM) и 50% памяти Optane. Эта демонстрация показывает истинную мощь VMware vSphere, а также техник ранжирования памяти и ускорения (проект Peaberry).

В среднем снижение производительности составило около 10%, при этом примерно 40% виртуальной памяти было доступно через ускоритель Peaberry. Обратите внимание, что tiering полностью прозрачен для приложения, поэтому это работает для всех типов рабочих нагрузок. Важно понимать, что поскольку гипервизор уже отвечает за управление памятью, он знает, какие страницы являются "горячими", а какие "холодными", а это значит, что он может определить, какие страницы можно переместить на другой уровень, сохраняя при этом производительность.

В общем, ждем больше интересной информации от VMware на эту тему!

На сайте проекта Sample Exchange появилась утилита vKaan - vSphere Health Check - решение для управления виртуальной средой, предназначенное для поддержания конфигураций инсталляций VMware vSphere. Пакет vKaan позволяет отслеживать конфигурации Cluster HA и DRS и идентифицировать различающиеся объекты. Он также выявляет нарушения правил vSphere DRS и генерирует оповещения. Идентифицируя нарушения правил, он помогает обеспечить стабильность, эффективность и соответствие вашей среды vSphere желаемому состоянию.

Требования к системе Aria Operations

• Для интеграции с пакетом управления версия vSphere API должна быть выше 8.0.1.0 (версии vSphere 7.x не поддерживаются).
• Версия Aria Operations Manager должна быть выше 8.10.x.

Требования к правам пользователя Aria Operations Manager

Сервисная учетная запись для Aria Operations должна иметь разрешение только на чтение (read-only) с выбранной опцией распространения на дочерние объекты (Propagate to children) в vCenter Server.

Руководство по установке

Инструкции по установке и развертыванию:

• Скачайте файл "vKaan - vSphere Health Check.zip" и извлеките его в папку.
• Установите файл "vKaan - vSphere Health Check-1.x.x.x.pak" через меню Data Sources > Integration > Repository.
• Импортируйте файл "vKaan - Cluster Configuration Views.xml" из меню Environment > Views.
• Добавьте ваш vCenter Server в vKaan через меню Data Sources > Integrations > Repository.
• После того как vKaan MP завершит сбор данных, вы сможете открыть представление "vKaan - Cluster Configuration Summary Dashboard".

Скачать vKaan - vSphere Health Check можно по этой ссылке.

VMware VMmark 4.0 - это бесплатный кластерный бенчмарк, который измеряет производительность и масштабируемость виртуальных корпоративных сред.

VMmark 4 продолжает использовать дизайн и архитектуру предыдущих версий VMmark, предоставляя улучшенную автоматизацию и отчетность. Он использует модульный дизайн нагрузки с разнородными приложениями, включающий обновленные версии нескольких нагрузок из VMmark 3, также в нем появились и новые современные приложения, которые более точно соответствуют современным корпоративным виртуальным средам.

VMmark 4 также включает инфраструктурные нагрузки, такие как vMotion, Storage vMotion, Cross vMotion и Clone & Deploy. В дополнение к ним, VMware vSphere DRS также работает в тестируемом кластере для балансировки нагрузок. В VMmark 4.0 было сделано улучшение полностью автоматизированного процесса развертывания, который появился в VMmark 3 - это сокращает время, необходимое пользователям для получения ценных результатов. Большинство пользователей теперь смогут перейти от загружаемого шаблона VMmark до результатов VMmark 4 примерно за два часа для "турбо" запуска.

Бенчмарк VMmark 4:

• Позволяет точно и повторяемо оценивать производительность виртуальных датацентров на основе vSphere.
• Использует разнообразные традиционные, устаревшие и современные нагрузки приложений в разнородном модульном подходе.
• Облегчает анализ и сравнение изменений в оборудовании, программном обеспечении и конфигурациях виртуальных сред VMware.
• Уровни создаваемой нагрузки теперь значительно выше, чем в предыдущих версиях VMmark, чтобы лучше отражать современные реалии.

Обновления удобства использования VMmark 4:

• Новый режим "Быстрый старт" для развертывания, запуска и получения результатов бенчмарка с помощью одной команды.
• Новые режимы развертывания, которые позволяют большую гибкость в распределении виртуальных машин по более разнообразным хранилищам.
• Функциональность частичных модулей (Partial Tile) для увеличения гранулярности бенчмарка через предписанное включение рабочих нагрузок приложений в конечный модуль.
• Дизайн "Автоматизация в первую очередь" - многие основные операции администрирования vSphere теперь доступны пользователям. Операции, такие как deleting_all_vmmark4, manual_xvmotion и power_vmmark4_tiles, помогают пользователям в полной автоматизации VMmark 4. Посмотрите вывод команды vmmark4service для получения списка из более чем 20 новых доступных операций.
• Улучшенная HTML-отчетность - пользователи теперь автоматически получают улучшенный HTML-вывод для пропускной способности, качества обслуживания и операций инфраструктуры для каждого запуска.
• Новое приложение "disclosure creator", которое упрощает и автоматизирует создание HTML файлов.
• Сбор данных о потреблении энергии - новый подход VMmark 4 к пониманию потребления энергопотребления. Этот режим собирает метрики энергопотребления на тестируемых системах и генерирует улучшенный HTML-отчет, чтобы помочь пользователям посчитать потребление энергии как хостами, так и виртуальными машинами.
• Интеграция оповещений - оповещения в Slack и Google Chat легко встраиваются в VMmark 4 и включаются одним параметром.

Рабочие нагрузки приложений VMmark 4:

• NoSQLBench - это новая рабочая нагрузка приложения в VMmark 4, используемая для анализа производительности новой распределенной NoSQL базы данных Apache Cassandra на 3 узлах.
• SocialNetwork - эта новая рабочая нагрузка приложения в VMmark использует Docker-контейнеры для моделирования социальной сети с операциями, такими как создание постов, подписка на пользователей и т.д.
• DVDstore (обновлено до версии 3.5) - включает PostgreSQL и параллельную загрузку базы данных, сокращая время на развертывание первого модуля.
• Weathervane (обновлено до версии 2.0) - это масштабируемое веб-приложение, имитирующее онлайн-аукцион, теперь работает в Kubernetes контейнерах и в виртуальных машинах.
• Standby - сервер Standby имитирует heartbeat-сервер, который периодически пингуется, чтобы убедиться, что он все еще работает и подключен.

Инфраструктурные нагрузки VMmark 4:

• vMotion - эта операция инфраструктуры выполняет живую миграцию одной из Standby ВМ по круговой схеме, чтобы смоделировать современные операции системного администратора.
• Storage vMotion - для этой операции одна из ВМ AuctionWebF мигрируется на указанное пользователем хранилище для обслуживания, а затем через некоторое время возвращается в исходное место.
• Cross vMotion (XvMotion) - эта операция одновременно перемещает одну из ВМ DS3WebA на альтернативный хост и хранилище для обслуживания. Аналогично операции Storage vMotion, через некоторое время ВМ возвращается в исходное место.
• Автоматическое балансирование нагрузки (DRS) - VMmark требует, чтобы DRS был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.

Скачать VMware VMmark 4.0 можно по этой ссылке.

Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.

VMware Tanzu — это огромная инновационная платформа, разработанная компанией VMware и принадлежащая сейчас Broadcom, предназначенная для управления современными приложениями в мультиоблачных средах. Tanzu предоставляет инструменты для разработки, развертывания и управления контейнеризированными приложениями с использованием Kubernetes. В этой статье мы рассмотрим ключевые аспекты экосистемы VMware Tanzu, и как она помогает организациям эффективно управлять своими приложениями.

Ключевыми компонентами VMware Tanzu являются следующие решения:

• Tanzu Kubernetes Grid (TKG)
• Tanzu Application Service (TAS)
• Tanzu Mission Control (TMC)
• Tanzu Observability
• Tanzu Application Catalog (TAC)
• Spring Boot

Многие продукты и технологии, которые вы знали ранее в продуктовом портфеле VMware (см. ниже о Wavefront или Cloud Foundry), были заведены под зонтик Tanzu (уже в составе Broadcom), который объединяет множество интересных направлений. Например, в состав экосистемы Tanzu входит решение Greenplum, которое представляет собой мощную и масштабируемую аналитическую базу данных с открытым исходным кодом, разработанную для выполнения сложных запросов и обработки больших объемов данных.

Кстати, посмотрите, как изменилась стоимость компании Broadcom, поглотившей VMware, с момента консолидации активов последней, в состав которых входят и решения Tanzu:

Основные компоненты VMware Tanzu

VMware Tanzu включает в себя несколько основных компонентов, которые вместе образуют мощную экосистему для управления приложениями:

1. Tanzu Kubernetes Grid (TKG)

TKG предоставляет готовое к использованию дистрибутив Kubernetes, который можно развернуть в различных средах, включая локальные дата-центры и публичные облака. TKG обеспечивает консистентность и масштабируемость, упрощая управление кластерами Kubernetes в различных окружениях.

Tanzu Kubernetes Grid является ключевым компонентом VMware Tanzu, предназначенным для упрощения развертывания и управления кластерами Kubernetes в мультиоблачных и локальных средах. TKG предлагает унифицированный подход к управлению Kubernetes, обеспечивая гибкость и консистентность, необходимые для современных приложений. Нижу мы рассмотрим основные возможности, архитектуру и преимущества TKG.

Основные возможности TKG:

• Единый дистрибутив Kubernetes
  TKG предоставляет готовый к использованию дистрибутив Kubernetes, который включает все необходимые компоненты для развертывания и управления кластерами. Это обеспечивает консистентность среды разработки и эксплуатации в различных окружениях.
• Мультиоблачная поддержка
  TKG поддерживает развертывание в различных облачных средах, включая AWS, Azure, Google Cloud, а также в локальных дата-центрах на базе vSphere. Это позволяет организациям выбирать наилучшее окружение для своих приложений.
• Автоматизация управления кластерами
  TKG автоматизирует многие аспекты управления кластерами Kubernetes, включая развертывание, обновление, масштабирование и мониторинг. Это сокращает трудозатраты и повышает эффективность операций.
• Интеграция с экосистемой VMware
  TKG интегрируется с другими продуктами VMware, такими как vSphere, vSAN и NSX, что обеспечивает высокую степень управления и безопасности для контейнеризированных приложений.
• Поддержка современных рабочих нагрузок
  TKG поддерживает развертывание и управление современными облачными приложениями, включая микросервисы и серверлесс-архитектуры, что позволяет организациям быстро адаптироваться к изменяющимся бизнес-требованиям.

Архитектура TKG:

• Управляющий кластер
  Management Cluster является основой инфраструктуры TKG. Он отвечает за управление всеми рабочими кластерами, включая их развертывание, обновление и масштабирование. Управляющий кластер также обеспечивает централизованное управление политиками и безопасностью.
• Рабочие кластеры
  Workload Clusters предназначены для развертывания приложений. Каждый рабочий кластер является полностью управляемым экземпляром Kubernetes, который может быть настроен и масштабирован в зависимости от потребностей приложения.
• Tanzu CLI
  Это командная строка, которая позволяет администраторам и разработчикам управлять кластерами Kubernetes и взаимодействовать с компонентами TKG. Tanzu CLI упрощает выполнение задач, таких как развертывание кластеров, обновление версий Kubernetes и управление политиками безопасности.
• Расширения Tanzu Kubernetes Grid Extensions
  TKG Extensions включают дополнительные компоненты и интеграции, которые расширяют возможности Kubernetes. Это включает мониторинг, журналирование, управление конфигурацией и сетевой политикой.

Преимущества использования TKG:

• Упрощение управления Kubernetes
  TKG значительно упрощает управление кластерами Kubernetes, предоставляя готовые к использованию инструменты и автоматизируя многие рутинные задачи. Это позволяет администраторам сосредоточиться на более стратегических задачах.
• Гибкость и масштабируемость
  С поддержкой мультиоблачных сред TKG обеспечивает высокую гибкость и масштабируемость, что позволяет организациям развертывать кластеры Kubernetes там, где это наиболее целесообразно с точки зрения производительности и затрат.
• Повышенная безопасность
  TKG интегрируется с инструментами безопасности VMware, такими как NSX, что обеспечивает высокую степень защиты для контейнеризированных приложений. Это включает сетевую сегментацию, контроль доступа и шифрование данных.
• Быстрое развертывание приложений
  TKG позволяет быстро развертывать и масштабировать приложения, что особенно важно в условиях динамически меняющихся бизнес-требований. Это обеспечивает конкурентное преимущество и ускоряет вывод новых продуктов на рынок.

Tanzu Kubernetes Grid (TKG) представляет собой мощное и гибкое решение для управления кластерами Kubernetes в мультиоблачных и локальных средах. Благодаря своим возможностям по автоматизации, интеграции с экосистемой VMware и поддержке современных рабочих нагрузок, TKG помогает организациям эффективно управлять своими приложениями и адаптироваться к изменяющимся бизнес-требованиям. В условиях быстро развивающегося ИТ-ландшафта TKG становится ключевым инструментом для успешного развертывания и эксплуатации облачных приложений.

Продолжить читать статью ->>

29 мая Vinchin выпустил обновленную версию решения Backup & Recovery 8.0. В этом обновлении, помимо стандартных улучшений функционала, добавлена поддержка новых платформ и расширены возможности для аварийного восстановления. В частности, теперь доступен бэкап российских виртуализационных решений - РЕД Виртуализация и ROSA Virtualization, а также их операционных систем - РЕД ОС и Astra Linux.